SSH ile Bağlanılamıyor: Adım Adım Sorun Giderme

Bir gece yarısı telefon çalıyor, “Sunucuya bağlanamıyorum, SSH çalışmıyor!” diyor karşıdaki ses. Bu sysadmin hayatının kaçınılmaz gerçeklerinden biri. SSH bağlantı sorunları hem acil hem de sinir bozucu olabiliyor, çünkü genellikle tam en kritik anlarda karşınıza çıkıyor. Bu yazıda SSH bağlantı sorunlarını sistematik bir şekilde nasıl çözeceğinizi, gerçek dünya senaryolarıyla birlikte adım adım anlatacağım.

Önce Nerede Olduğunuzu Anlayın

SSH bağlantısı kuramadığınızda paniklemek yerine önce birkaç temel soruyu kendinize sorun:

• Daha önce bu sunucuya bağlanabiliyor muydunuz?
• Sunucu fiziksel olarak erişilebilir mi, yani ping atıyor mu?
• Sadece siz mi bağlanamıyorsunuz, herkes mi?
• Son yapılan değişiklik ne?

Bu soruların cevapları sizi doğru yöne yönlendirecek. “Son değişiklik” sorusu özellikle çok kritik. Çoğu SSH sorunu aslında birinin bir şeyi değiştirmesinden kaynaklanıyor.

Adım 1: Temel Ağ Bağlantısını Kontrol Edin

En basit adımdan başlayalım. Sunucu ağda var mı?

ping -c 4 192.168.1.100
# veya hostname ile
ping -c 4 sunucu.example.com

Ping çalışıyorsa sunucu fiziksel olarak erişilebilir demektir. Ping çalışmıyorsa sorun SSH’dan önce ağ katmanında. Ama bazı sunucularda ICMP engellenmiş olabilir, o yüzden ping’in çalışmaması her zaman sunucunun kapalı olduğu anlamına gelmiyor.

SSH portunun açık olup olmadığını kontrol etmek için:

# Varsayılan 22 portu için
nc -zv 192.168.1.100 22
# veya
telnet 192.168.1.100 22

# Özel port kullanıyorsanız
nc -zv 192.168.1.100 2222

nc çıktısında Connection refused görüyorsanız SSH servisi çalışmıyor demektir. Connection timed out görüyorsanız büyük ihtimalle güvenlik duvarı engelliyor.

Daha ayrıntılı port taraması için nmap kullanabilirsiniz:

nmap -p 22 192.168.1.100
nmap -p 22,2222 192.168.1.100

Adım 2: SSH İstemci Tarafında Verbose Mod

Sunucu erişilebilir ama SSH bağlanamıyorsa, SSH istemcisini verbose modda çalıştırarak ne olduğunu görebilirsiniz. Bu benim en çok kullandığım ilk adımlardan biri:

ssh -v [email protected]
# Daha fazla detay için
ssh -vv [email protected]
# Maksimum detay
ssh -vvv [email protected]

Verbose çıktısında dikkat etmeniz gereken satırlar:

• debug1: Connecting to…: Bağlantı denemesi başladı
• debug1: Connection established: TCP bağlantısı kuruldu
• debug1: Authenticating to…: Kimlik doğrulama aşamasına geçildi
• Permission denied: Kimlik doğrulama başarısız
• Connection refused: SSH servisi çalışmıyor veya port kapalı

Gerçek hayattan bir örnek: Verbose çıktısında debug1: Offering public key satırını görüp hemen ardından Server accepts key yerine Permission denied geliyorsa, sunucu tarafında authorized_keys dosyasında sorun var demektir.

Adım 3: SSH Servisinin Durumunu Kontrol Edin

Eğer sunucuya console erişiminiz varsa (KVM, IPMI, vSphere konsolu gibi), SSH servisini kontrol edin:

# Systemd kullanan sistemler için
systemctl status sshd
# veya
systemctl status ssh

# Eski SysV init sistemler için
service ssh status
/etc/init.d/ssh status

Servis çalışmıyorsa başlatın:

systemctl start sshd
systemctl enable sshd  # Otomatik başlatma için

SSH servisinin log’larına bakmak da çok işe yarıyor:

# Systemd journal ile
journalctl -u sshd -n 50
journalctl -u sshd --since "1 hour ago"

# Geleneksel log dosyası
tail -100 /var/log/auth.log          # Debian/Ubuntu
tail -100 /var/log/secure            # RHEL/CentOS/Fedora

Log’larda sshd[xxxx]: error: Could not load host key gibi bir şey görüyorsanız, SSH host anahtarları bozulmuş veya eksik olabilir.

Adım 4: Güvenlik Duvarı Kurallarını Kontrol Edin

SSH sorunlarının büyük bir kısmı güvenlik duvarından kaynaklanıyor. Hem sunucu üzerindeki hem de ağ üzerindeki güvenlik duvarlarını kontrol etmek gerekiyor.

iptables ile kontrol:

# Mevcut kuralları listele
iptables -L -n -v
# SSH portuna özel
iptables -L -n -v | grep -E "22|ssh"

# INPUT chain'ini kontrol et
iptables -L INPUT -n -v --line-numbers

firewalld ile kontrol (RHEL/CentOS 7+):

firewall-cmd --list-all
firewall-cmd --list-services
firewall-cmd --query-service=ssh

# SSH'a izin vermek için
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload

UFW ile kontrol (Ubuntu):

ufw status verbose
ufw allow ssh
# veya özel port için
ufw allow 2222/tcp

Bulut ortamlarında çalışıyorsanız (AWS, Azure, GCP), sunucu üzerindeki güvenlik duvarına ek olarak Security Group veya Network Security Group kurallarını da kontrol etmeyi unutmayın. Çok sık yapılan hata: Sunucuda her şey doğru ama AWS Security Group’ta port 22 kapalı.

Adım 5: SSH Konfigürasyon Dosyasını İnceleyin

SSH konfigürasyonu /etc/ssh/sshd_config dosyasında tutuluyor. Yanlış bir konfigürasyon her şeyi bozabilir.

# Konfigürasyon dosyasını görüntüle
cat /etc/ssh/sshd_config | grep -v "^#" | grep -v "^$"

# Konfigürasyon sözdizimini kontrol et
sshd -t
# Daha ayrıntılı
sshd -T

sshd -t komutu harika bir araç. Konfigürasyon dosyasında sözdizimi hatası varsa bunu size söyler, servisi yeniden başlatmadan önce kesinlikle çalıştırmanızı öneririm.

Dikkat etmeniz gereken kritik parametreler:

• Port: SSH’ın hangi portu dinlediği, varsayılan 22
• PermitRootLogin: Root ile doğrudan giriş izni
• PasswordAuthentication: Parola ile kimlik doğrulama
• PubkeyAuthentication: Anahtar tabanlı kimlik doğrulama
• AllowUsers / DenyUsers: Hangi kullanıcıların bağlanabileceği
• AllowGroups / DenyGroups: Hangi grupların bağlanabileceği
• ListenAddress: SSH’ın hangi IP adresinde dinlediği
• MaxAuthTries: Maksimum kimlik doğrulama denemesi

Gerçek hayat senaryosu: Bir gün bir müşteri “yeni bir kullanıcı oluşturduk ama SSH ile bağlanamıyor” dedi. Baktım, sshd_config dosyasında AllowUsers deploy admin yazıyor. Yeni kullanıcı bu listeye eklenmemiş. AllowUsers direktifi varsa, listedeki kullanıcılar dışındaki herkes bağlanamıyor. Çözüm basit ama bulmak zaman alıyor.

Adım 6: Anahtar Tabanlı Kimlik Doğrulama Sorunları

Parola ile bağlanabiliyor ama anahtar ile bağlanamıyorsanız, ya da “Permission denied (publickey)” hatası alıyorsanız:

İstemci tarafında kontrol:

# Mevcut anahtarları listele
ls -la ~/.ssh/
ssh-add -l

# Özel anahtar dosyasının izinlerini kontrol et
ls -la ~/.ssh/id_rsa
# İzinler 600 olmalı
chmod 600 ~/.ssh/id_rsa
chmod 700 ~/.ssh/

Sunucu tarafında kontrol:

# Hedef kullanıcının home dizini ve .ssh klasör izinleri
ls -la /home/username/
ls -la /home/username/.ssh/
ls -la /home/username/.ssh/authorized_keys

# İzinler kritik!
# Home dizini: 755 veya daha kısıtlayıcı
# .ssh dizini: 700
# authorized_keys: 600
chmod 700 /home/username/.ssh
chmod 600 /home/username/.ssh/authorized_keys

SSH izin konusunda çok katı. authorized_keys dosyası başkalarının yazma iznine sahipse, SSH güvenlik gerekçesiyle o anahtarı reddediyor. Bu yüzden izinleri her zaman kontrol edin.

Anahtarı doğru formatta eklediniz mi?

# Public anahtarı authorized_keys'e doğru şekilde eklemek için
ssh-copy-id -i ~/.ssh/id_rsa.pub user@sunucu

# Manuel ekleme yapıyorsanız
cat ~/.ssh/id_rsa.pub >> /home/username/.ssh/authorized_keys

SELinux sorunu olabilir mi?

RHEL/CentOS sistemlerinde SELinux bazen SSH anahtar kimlik doğrulamasını engelleyebilir:

# SELinux durumunu kontrol et
getenforce
sestatus

# SELinux audit loglarına bak
ausearch -m avc -ts recent | grep sshd

# .ssh dizini için SELinux context'ini düzelt
restorecon -R -v ~/.ssh

Adım 7: Host Key Sorunları

“WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!” hatası alıyorsanız, bu genellikle sunucu yeniden kurulmuş veya IP adresi değişmiş demektir.

# Bilinen host'lar dosyasından eski kaydı sil
ssh-keygen -R 192.168.1.100
ssh-keygen -R sunucu.example.com

# Veya manuel olarak
nano ~/.ssh/known_hosts
# İlgili satırı bulup sil

Bu uyarıyı dikkate alın. Gerçekten bir man-in-the-middle saldırısı da olabilir. Sunucunun gerçekten değiştiğinden emin olmadan bu uyarıyı geçiştirmeyin.

Adım 8: Port Değişikliği Yapıldıysa

Güvenlik gerekçesiyle SSH portu 22’den başka bir porta taşınmışsa:

# Özel port ile bağlanma
ssh -p 2222 [email protected]

# ~/.ssh/config dosyasına ekleyerek kalıcı hale getirme
nano ~/.ssh/config

Host sunucu-alias
    HostName 192.168.1.100
    User username
    Port 2222
    IdentityFile ~/.ssh/id_rsa

Bu yapılandırmadan sonra sadece ssh sunucu-alias yazmanız yeterli oluyor.

Adım 9: Brute Force Koruması Devreye Girmiş Olabilir

Çok fazla başarısız giriş denemesinin ardından fail2ban veya benzeri bir araç IP adresinizi geçici olarak engelliyor olabilir.

# fail2ban durumunu kontrol et
fail2ban-client status
fail2ban-client status sshd

# Engellenmiş IP'leri görüntüle
fail2ban-client status sshd | grep "Banned IP"

# IP'nin engelini kaldır
fail2ban-client unban 1.2.3.4
# veya eski versiyon
fail2ban-client set sshd unbanip 1.2.3.4

/etc/hosts.deny dosyasını da kontrol edin:

cat /etc/hosts.deny
cat /etc/hosts.allow

TCP Wrappers kullanılıyorsa burada engellenmiş olabilirsiniz.

Adım 10: Disk Dolu Sorunu

Bu kulağa garip gelebilir ama disk dolduğunda SSH bağlantısı sorunları yaşanabiliyor. SSH bağlanıyor ama oturum hemen kapanıyorsa, .bash_profile veya .bashrc çalışırken hata alıyor olabilir.

# Disk kullanımını kontrol et (console üzerinden)
df -h
du -sh /var/log/*

# /tmp dolmuş olabilir
du -sh /tmp

# Log rotation çalışıyor mu?
ls -la /var/log/syslog*

Disk doluysa:

# Büyük dosyaları bul
find / -type f -size +100M 2>/dev/null
# Log dosyalarını temizle
truncate -s 0 /var/log/syslog
journalctl --vacuum-size=500M

Adım 11: SSH Bağlantısı Oluşuyor Ama Hemen Kesiliyor

Bağlantı kuruluyor ama oturum saniyeler içinde kapanıyorsa, kullanıcının shell’inde sorun olabilir:

# Kullanıcının shell'ini kontrol et
grep username /etc/passwd

# Shell var mı?
ls -la /bin/bash
ls -la /usr/bin/false  # Eğer shell bu ise bağlanamaz

# Kullanıcı hesabı kilitli mi?
passwd -S username
# veya
usermod -U username  # Kilidi aç

.bashrc veya .bash_profile dosyasındaki bir hata da oturumun hemen kapanmasına neden olabilir:

# Sorunlu satırı devre dışı bırakarak bağlanmayı dene
ssh user@sunucu "bash --norc --noprofile"

Pratik Troubleshooting Akışı

Tüm bu adımları bir araya getiren pratik bir kontrol listesi:

# 1. Ping testi
ping -c 4 SUNUCU_IP

# 2. Port erişilebilirlik
nc -zv SUNUCU_IP 22

# 3. Verbose SSH bağlantısı
ssh -vvv user@SUNUCU_IP

# 4. Console erişimi varsa servis durumu
systemctl status sshd
journalctl -u sshd -n 30

# 5. Güvenlik duvarı
iptables -L -n | grep 22
firewall-cmd --list-all

# 6. Konfigürasyon kontrolü
sshd -t
grep -v "^#" /etc/ssh/sshd_config | grep -v "^$"

# 7. İzin kontrolü
ls -la ~/.ssh/
ls -la ~/.ssh/authorized_keys

Önleyici Tedbirler

Sorun yaşamamak için önceden alınabilecek önlemler:

• Her zaman ikinci bir terminal açık tutun: SSH konfigürasyonunu değiştirirken mevcut oturumu kapatmayın. Bir şeyler ters giderse geri alabilirsiniz.
• Konfigürasyon değişikliği öncesi test edin: sshd -t komutunu alışkanlık haline getirin.
• Düzenli anahtar yönetimi: Kullanılmayan anahtarları authorized_keys dosyasından temizleyin.
• Güvenlik duvarı değişikliklerini kayıt altına alın: Kimin hangi kuralı ne zaman eklediğini bilmek sorun gidermeyi hızlandırır.
• Out-of-band erişim: Her sunucu için IPMI, iDRAC, ILO veya cloud console gibi alternatif erişim yöntemi hazır olsun. SSH gittiğinde bu sizi kurtarır.

Sonuç

SSH sorunları çoğunlukla basit nedenlerden kaynaklanıyor: yanlış izinler, güvenlik duvarı kuralları, servisin çalışmaması veya konfigürasyon hatası. Paniklemek yerine sistematik bir şekilde katman katman ilerlemek hem zamandan hem de sinir harcamaktan sizi kurtarıyor.

En önemli alışkanlık: değişiklik yapmadan önce test etmek ve geri alma planı hazırlamak. SSH konfigürasyonunu değiştirirken mevcut bağlantınızı kapatmayın, servisi yeniden başlatmadan önce sözdizimini kontrol edin, ve her zaman alternatif bir erişim yönteminiz olsun.

Bu yazıdaki adımların %90’ını verbose mod SSH çıktısı ve servis log’ları zaten size söylüyor. Hata mesajlarını okumayı alışkanlık haline getirirseniz, çoğu sorunu ilk birkaç dakikada çözebilirsiniz.