SSH bağlantısı zaman aşımına uğruyorsa ne incelenir?

SSH bağlantısı zaman aşımına uğruyorsa önce sorunun hangi aşamada kaldığını ayırın: alan adı/IP çözümlemesi, istemciden sunucuya TCP erişimi, sunucuda SSH servisinin dinlemesi veya ağ güvenlik duvarı. İstemcide ayrıntılı günlük alın, aynı hedefe 22 numaralı TCP portunu test edin; bağlantı sunucuya ulaşıyorsa sunucu tarafında dinleme adresi, güvenlik duvarı ve günlükleri inceleyin. Zaman aşımı genellikle karşı uçtan yanıt alınamadığını gösterir; yanlış kullanıcı adı ya da anahtar hatası ise çoğunlukla zaman aşımından sonra değil, kimlik doğrulama aşamasında açık bir hata üretir.

Sorunun hangi aşamada olduğunu belirleme​

İlk olarak kullandığınız hedefin gerçekten doğru olduğunu kontrol edin. Alan adı birden fazla IP adresine, eski bir DNS kaydına veya farklı bir sunucuya yönleniyor olabilir. Varsayımsal hedefiniz example.com, SSH portunuz da 22 olsun. İstemcide şu komutu çalıştırın:


Çıktıda Connecting to example.com ... port 22 satırından sonra uzun süre bekleyip zaman aşımı alıyorsanız sorun henüz kimlik doğrulamaya ulaşmamıştır. Bu durumda parola, özel anahtar veya kullanıcı hesabına odaklanmayın; ağ erişimini test edin.

Alan adının hangi adrese çözüldüğünü ayrıca kontrol edin:


Çıktı beklediğiniz sunucuyu göstermiyorsa DNS kaydı, yerel DNS önbelleği veya yanlış hedef problemi vardır. Doğru IP’yi biliyorsanız alan adını devre dışı bırakıp örnek dokümantasyon adresiyle doğrudan test edebilirsiniz:


Bu adres yalnızca örnek içindir; gerçek sunucunuzun IP adresiyle değiştirin.

DNS hem A hem AAAA döndürüyorsa ssh -4 veya ssh -6 ile IPv4/IPv6 yolunu ayrı deneyin. IP ile bağlantı yeni bir known_hosts eşlemesi oluşturabilir; parmak izini bağımsız güvenilir kaynaktan doğrulayın, host-key kontrolünü kapatmayın. ConnectTimeout bağlantı kurulması ve başlangıç SSH el sıkışmasını sınırlar; oturum açıldıktan sonraki tüm işleri kapsayan genel süre limiti değildir.

TCP portuna erişimi test etme​

SSH servisine ulaşılabilir olup olmadığını, oturum açmadan da test edebilirsiniz. nc kurulu bir istemcide:


Başarılı bir sonuç TCP bağlantısı kurulabildiğini gösterir; porttaki hizmetin gerçekten SSH veya tüm handshake’in başarılı olduğu anlamına gelmez. Bu durumda sorun SSH yapılandırması, kimlik doğrulama veya sunucu politikası tarafında aranmalıdır. timed out veya benzeri bir sonuç, trafiğin yol üzerinde engellendiğini, yanlış IP’ye gittiğini ya da sunucunun yanıt vermediğini düşündürür. connection refused ise hedefe ulaşıldığını, ancak o portta dinleyen servis bulunmadığını veya bağlantının aktif biçimde reddedildiğini gösterir.

Windows istemcisinde eşdeğer test için PowerShell kullanabilirsiniz:


TcpTestSucceeded : True sonucu TCP erişimini doğrular. False sonucu ise ağ yolu, güvenlik duvarı, IP veya port yönlendirmesi incelenmeden SSH anahtarı değiştirilmemesi gerektiğini gösterir.

Aşağıdaki tablo, test sonucuna göre sonraki adımı seçmeye yardımcı olur.

Sunucu tarafında kontrol listesi​

Sunucu konsoluna, sağlayıcının kurtarma konsoluna veya çalışan başka bir yönetim oturumuna erişebiliyorsanız şu sırayla ilerleyin:

1. SSH servisinin çalıştığını kontrol edin: systemctl status sshd. Dağıtımınızda servis adı ssh olabilir; ilk komut bulunamazsa systemctl status ssh kullanın. Servis durmuşsa önce yapılandırma hatasını ve servis günlüklerini inceleyin.
2. Gerçekten hangi port ve adresin dinlendiğini görün: ss -lntp '( sport = :22 )'. Yalnızca 127.0.0.1:22 görünüyorsa servis dış ağdan bağlantı kabul etmiyordur. Farklı bir port dinleniyorsa istemcide o portu -p seçeneğiyle belirtin.
3. SSH yapılandırmasının geçerli olup olmadığını test edin: sshd -t. Komut hata verirse yapılandırmayı düzeltmeden servisi yeniden başlatmayın; aksi durumda çalışan yönetim oturumunu kaybetme riski vardır.
4. İşletim sistemi ve ağ güvenlik duvarında SSH portuna izin verildiğini, ayrıca bulut güvenlik grubu, NAT veya sağlayıcı erişim listesinin doğru IP’den gelen trafiği engellemediğini kontrol edin.
5. Logda satır olmaması paketin kesin ulaşmadığını kanıtlamaz; yanlış servis/log hedefi, seviye veya handshake öncesi kesilme de olabilir. Konsol erişimiyle ağ ve servis katmanını birlikte kontrol edin. Deneme görünüyorsa reddetme, erişim sınırı, yanlış port veya SSH yapılandırması gibi sunucu içi nedenlere odaklanın.

Portu değiştirmek tek başına çözüm değildir. Yeni port hem SSH yapılandırmasında hem de sunucu güvenlik duvarı, sağlayıcı güvenlik grubu ve varsa yönlendiricide birlikte açılmalıdır. Değişiklikten sonra mevcut oturumu kapatmadan ikinci bir terminalden yeni portu test edin. Bağlantı hâlâ zaman aşımına uğruyorsa en değerli ayrım, istemci debug çıktısı ile sunucu günlüklerindeki denemenin eşleşip eşleşmediğidir.

Sık yapılan anlamlı hatalar​

• Ping yanıtını SSH erişiminin kanıtı saymak: ICMP kapalı olabilir; SSH için doğrudan TCP portunu test edin.
• Yanlış IP’ye anahtar veya parola sorunuyla müdahale etmek: Önce DNS sonucunu ve hedef IP’yi doğrulayın.
• Sadece sunucu içindeki güvenlik duvarını incelemek: İstemci çıkışı, bulut güvenlik grubu, NAT ve ara ağ cihazları da bağlantıyı engelleyebilir.
• Yapılandırmayı doğrulamadan SSH servisini yeniden başlatmak: sshd -t ile sözdizimini test edin ve açık yönetim oturumunu koruyun.
• Zaman aşımı ile reddedilmeyi aynı kabul etmek: Zaman aşımı çoğunlukla yanıtın düşürüldüğünü, reddedilme ise hedefe ulaşılıp portta servis bulunmadığını gösterir.
  

Kaynaklar​

• OpenSSH: ConnectTimeout ve AddressFamily
• OpenSSH: sshd kontrolü
• Linux: ss soket filtresi

Sık sorulan sorular​

SSH portu 22 değilse nasıl anlaşılır?​

Sunucu yapılandırmasındaki Port değerini ve dinleyen soketleri kontrol edin. Doğru portu bulduktan sonra ssh -p PORT [email protected] biçiminde bağlanın; ağ güvenlik kurallarında da aynı portun izinli olduğundan emin olun.

Aynı sunucuya başka bir ağdan bağlanabiliyorsam sorun nerede olabilir?​

Sunucunun kendisinden çok ilk ağın çıkış güvenlik duvarı, VPN rotası, NAT veya IP tabanlı erişim kuralı şüphelidir. Her iki ağdan DNS sonucunu ve TCP port testini karşılaştırın.