SSH bağlantı hataları: timeout, refused ve permission denied
Nereden başlamalı? Ekrandaki hatayı aşağıdaki tabloda bulun ve ilgili adımı izleyin. Sunucuya ulaşılamaması ile sunucunun girişinizi kabul etmemesi farklı sorunlardır.
SSH bağlantı hatasının tam metni, sorunun hangi aşamada olduğunu gösterir. Zaman aşımı, reddedilen bağlantı ve kimlik doğrulama hatasına aynı işlemi uygulamak sorunu büyütebilir. Önce hata mesajını, işlem zamanını ve son yapılan değişikliği not edin.
Kapsam: OpenSSH istemcisi; sunucu tarafı komutları için Ubuntu 24.04 LTS veya Debian 13. Bu rehber başlangıçta ayar değiştirmeyen kontroller yapar. Açık bir SSH oturumunuz varsa kapatmayın. Konsol veya kurtarma erişiminin her hizmette bulunduğunu varsaymayın.
Hata mesajı, kontrol edeceğiniz aşamayı seçmenize yardımcı olur.
- Adres
Sunucu adı çözümlenebiliyor mu? IP ve yazımı doğrulayın.
- Ağ ve port
Hedef SSH portu yanıt veriyor mu? Timeout ve refused bu aşamayı inceletir.
- Sunucu kimliği
Parmak izi kayıtlı kimlikle aynı mı? Değişikliği doğrulamadan ilerlemeyin.
- Kullanıcı ve anahtar
Giriş yöntemi kabul ediliyor mu? Permission denied için hesap ve anahtarı kontrol edin.
Açık çalışan bir SSH oturumu varsa kapatmayın; hata türüne göre ilgili bölümü izleyin.
1. Adres, kullanıcı ve portu doğrulayın
Üç bilgiyi tek tek karşılaştırın: IP adresi → SSH kullanıcı adı → SSH portu. Aşağıdaki 203.0.113.10, sunucu_kullanicisi ve 22 yalnız örnektir.
DCHost müşteri portalındaki ilgili hizmetin kurulum bilgilerini kontrol edin. Hosting paneli parolası, SSH hesabınızın parolası olmayabilir. Örnek IP, kullanıcı ve portu kendi bilgilerinizle değiştirerek bilgisayarınızda deneyin:
ssh -p 22 sunucu_kullanicisi@203.0.113.10
Portu rastgele değiştirmeyin; hizmetin gerçekten dinlediği SSH portunu kullanın. Sonucu aşağıdaki hata türüyle eşleştirin.
Kontrol: Bağlantı açılmadıysa çıkan tam mesajı kaydedin. Sonraki tabloda aynı ifadeyi bulun.
2. Hatanın oluştuğu aşamayı ayırın
Nasıl kullanılır? Tam hata mesajınızı ilk sütunda bulun. Son sütun, ilk bakacağınız yeri gösterir. Bir hata için önerilen işlemi diğer hatalara uygulamayın.
| Hata | Anlamı | İlk kontrol |
|---|---|---|
Could not resolve hostname | İstemci sunucu adını IP'ye çeviremedi | Yazım, DNS ve hizmetteki IP adresi |
Connection timed out | Bağlantı beklenen sürede yanıt almadı | Doğru IP/port, sunucu durumu, ağ ve erişim kuralları |
Connection refused | Hedef veya aradaki ağ cihazı bağlantıyı reddetti | Dinleyen servis/port ve reddeden güvenlik kuralı |
Permission denied | Kimlik doğrulama tamamlanamadı | Kullanıcı, izin verilen giriş yöntemi ve anahtar/parola |
REMOTE HOST IDENTIFICATION HAS CHANGED | Sunucu anahtarı kayıtlı kimlikle uyuşmuyor | Yeniden kurulum, IP değişimi ve güvenilir parmak izi doğrulaması |
Ping yanıtı alınamaması sunucunun kapalı olduğunu tek başına göstermez; ICMP engellenmiş olabilir. Benzer şekilde web sitesinin açılması, SSH portunun erişilebilir olduğunu kanıtlamaz.
3. Zaman aşımı veya reddedilen bağlantıyı inceleyin
Tam mesajı okuyun; düzeltmeyi hatanın bulunduğu aşamaya göre seçin.
- Connection timed out
Zamanında yanıt yok: IP, port, sunucu durumu ve ağ erişimini inceleyin.
- Connection refused
Bağlantı reddedildi: SSH dinleyicisini ve reddeden erişim kurallarını kontrol edin.
- Permission denied
Giriş kabul edilmedi: kullanıcı, izin verilen yöntem ve anahtar/parolayı doğrulayın.
Sunucuya hiç erişemiyorsanız sunucu komutlarını kendi bilgisayarınızda çalıştırmayın; destek isteyin.
Önce bilgisayarınızın bağlantısını inceleyin:
- IP ve portu hizmet bilgileriyle yeniden karşılaştırın.
- Şirket ağı veya VPN kullanıyorsanız porta izin verilip verilmediğini kontrol edin.
- Mümkünse güvendiğiniz başka bir ağdan aynı hedefi deneyin.
Hiç sunucu erişiminiz yoksa: Aşağıdaki sunucu komutlarını bilgisayarınızda çalıştırmayın. Destek talebi hazırlama bölümüne geçin.
Kendi ağınızın dışarıya ilgili porttan bağlantıya izin verdiğini kontrol edin. VPN veya kurumsal güvenlik politikası varsa ağ yöneticinizle görüşün. Farklı, güvendiğiniz bir bağlantıdan aynı adres ve portu denemek sorunun tek bir ağa özgü olup olmadığını ayırabilir.
Sunucuda halen çalışan bir oturum veya doğrulanmış konsol erişimi varsa aşağıdaki salt okunur kontrolleri yapabilirsiniz. sudo kullanılan komutlar için hesabınızın gerekli yönetici yetkisine sahip olması gerekir; yetki yoksa sunucu yöneticinizden bu çıktıları isteyin:
systemctl status ssh.service ssh.socket --no-pager
sudo ss -ltnp
sudo journalctl -u ssh.service --since "30 minutes ago" --no-pager
Bazı kurulumlarda socket etkinleştirmesi kullanılır; yalnız ssh.service durumuna bakarak sonuca varmayın. ssh.socket biriminin bulunmaması da her kurulumda hata değildir. ss çıktısında beklediğiniz portun dinlenip dinlenmediğini kontrol edin. Günlükteki zamanı bağlantı denemenizle eşleştirin.
Erişim kurallarını değerlendirmeden güvenlik duvarını kapatmayın veya kuralları temizlemeyin. Mevcut oturum, ikinci bir bağlantı ve kullanabildiğiniz kurtarma yöntemi doğrulanmadan SSH portu ya da firewall değişikliği yapmayın. Hiçbir erişiminiz yoksa bu komutları çalıştırabileceğinizi varsaymak yerine hizmet bilgileriyle destek talebi açın.
| Komut | Sonuçta ne aramalısınız? |
|---|---|
systemctl status | SSH hizmeti veya dinleyen socket biriminin durumu |
ss -ltnp | Gerçek SSH portunuz için LISTEN satırı |
journalctl | Deneme saatinizle eşleşen SSH kaydı |
--since "30 minutes ago", son 30 dakikayı seçer. Günlüğün boş olması tek başına bağlantının sağlıklı olduğunu göstermez.
4. Kullanıcı ve anahtar hatasını inceleyin
Bu sırayla kontrol edin: doğru kullanıcı → doğru özel anahtar → izin verilen giriş yöntemi. Anahtar ilgili kullanıcı için tanımlıdır; başka kullanıcı adıyla aynı sunucuya bağlanmanız yeterli olmaz.
Permission denied (publickey) durumunda doğru kullanıcıyı ve o kullanıcı için tanımlanmış özel anahtar dosyasını seçtiğinizden emin olun. Sunucu parola girişine izin vermiyorsa parola değiştirmeniz yeterli olmaz. SSH anahtarı rehberindeki dosya ve izin kontrollerini çalışan bir oturumdan yapın.
Daha ayrıntılı istemci kaydı için bilgisayarınızda ssh -v -p 22 sunucu_kullanicisi@203.0.113.10 komutunu kullanabilirsiniz. Bu kayıt kullanıcı adı, IP, dosya yolları ve anahtar bilgileri içerebilir. Paylaşmadan önce gereksiz kişisel bilgileri ayıklayın; özel anahtar dosyanızı veya parolanızı eklemeyin.
Beklenen sonuç: -v eklenmiş komut, denenen giriş yöntemleri ve hatanın aşaması hakkında ek satırlar yazar. Bu seçenek sorunu kendiliğinden düzeltmez.
5. Sunucu kimliği değiştiyse doğrulamadan ilerlemeyin
Önce doğrulayın, sonra kayıt kaldırın. Parmak izi, sunucunun kimliğini kontrol etmek için kullanılan değerdir. Uyarının kaybolması tek başına doğru sunucuya bağlandığınızı kanıtlamaz.
Yeniden kurulum SSH sunucu anahtarını değiştirebilir; aynı uyarı yanlış sunucuya bağlanmanızda da görülür. Yeni SHA256 parmak izini güvenilir hizmet bilgisi veya destek kanalıyla doğrulayın. Kontrolü atlayan StrictHostKeyChecking=no gibi seçeneklerle bağlanmayın.
Değişikliğin doğru olduğu doğrulandıktan sonra eski kaydı yalnız ilgili hedef için kaldırabilirsiniz. Kendi bilgisayarınızda, standart portla kullanılan örnek IP için:
ssh-keygen -R 203.0.113.10
Özel port kullanıyorsanız kayıt biçimi [IP]:port olur; örneğin ssh-keygen -R '[203.0.113.10]:2222'. Ardından yeniden bağlanırken gösterilen parmak izini teyit ettiğiniz değerle karşılaştırın. Bütün known_hosts dosyasını silmeyin. Bu işlem sunucunun ayarını değiştirmez; bilgisayarınızdaki o hedefe ait eski güven kaydını kaldırır.
Kontrol: Eski kayıt bulunursa kaldırıldığı bildirilir. Sonraki bağlantıda sunulan yeni parmak izi, önceden doğruladığınız değerle aynı olmalıdır.
Destek talebini hazırlayın
Hizmet numarası, saat dilimiyle deneme zamanı, hedef port, tam hata mesajı ve son değişikliği belirtin. İnceleme için kaynak IP gerekirse yalnız özel destek kanalında paylaşın. Sunucuyu yeniden kurmak, disk biçimlendirmek veya rastgele yeniden başlatmak ilk teşhis adımı değildir. Destek talebi rehberindeki şablonu kullanabilirsiniz.