Ubuntu VPS SSH bağlantı hataları nasıl giderilir?

Çalışan erişimi koruyup hatayı kaydedin

Başarılı SSH oturumu varsa açık tutun ve sağlayıcının kurtarma konsolunu bulun. İstemci komutları kendi bilgisayarınızda Linux, macOS veya WSL içinde; sunucu komutları mevcut bağlantı ya da kimliği doğrulanmış konsolda çalışır. Sunucu komutlarını yerel terminale yapıştırmayın.

203.0.113.10 yerine gerçek adresi; ubuntu, 22 ve anahtar yolu yerine kullandığınız değerleri yazın. Önce istemcinin hesaplanmış ayarlarını görün, sonra yeni bir bağlantı deneyin.

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

hostname, user, port, identityfile ve proxy ayarlarını kontrol edin. İkinci komut bu deneme için bağlantı paylaşımını kapatır. Saati ve son hatayı kaydedin. Yeni sunucu anahtarı sorusunu kimlik bölümüne göre doğrulayın. Debug çıktısını paylaşırken hesap, adres ve yolları temizleyin; özel anahtarı paylaşmayın.

Mesajın gösterdiği dala geçin

Diğer sütunlar için tabloyu yana kaydırın →

Bunlar nedeni daraltır, tek bir nedeni kanıtlamaz. Çıktıda zaman aşımından önce Connection established varsa tüm paketlerin engellendiğini varsaymayın; SSH el sıkışmasını ve sunucu günlüklerini inceleyin.

Zaman aşımında gerçek ağ yolunu izleyin

ssh -v hedefini sağlayıcı panelindeki güncel adresle karşılaştırın. Alan adı eski DNS veya farklı IPv6 hedefine gidebilir. VPS’nin genel IP, VPN ya da atlama sunucusu gerektirip gerektirmediğini belirleyin.

VM’nin çalıştığını ve genel rotasının bulunduğunu kontrol edin. Sağlayıcı firewall kuralındaki hedef SSH portunu ve güncel genel kaynak IP’nizi doğrulayın. Ev bağlantısının IP’si değişirken /32 izni eski kalabilir. Konsoldan konuk sistem firewall durumunu da inceleyin.

Oracle Cloud’da security list, NSG, rota ve konuk firewall birlikte etkilidir. İmajın kurallarını koruyun; UFW kurmak veya iptables temizlemek teşhis değildir. Oracle ağ kurulumunu kontrol edin. Başarısız ping tek başına SSH erişiminin olmadığını kanıtlamaz.

Reddedilen bağlantıda dinleyiciyi kontrol edin

Connection refused, hedefin doğru VPS olduğunu doğrulamaz. Kimlik ve portu kontrol ettikten sonra sunucuda mevcut erişim veya kurtarma konsolu üzerinden bu salt okunur komutları çalıştırın.

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

Beklenen port ve adreste dinleyici arayın; günlükleri deneme saatiyle eşleştirin. Ubuntu socket activation kullanabilir: ssh.socket dinliyorsa ssh.service durumunun inactive olması tek başına erişim yok demek değildir.

sshd -t yapılandırma ve sunucu anahtarlarını servis başlatmadan denetler. Sessiz başarı ağ erişimini kanıtlamaz. Hata varsa yeniden yüklemeden önce dosya veya ayarı belirleyin; servisi rastgele yeniden başlatmayın.

Reddedilen anahtarda hesap ve kimliği karşılaştırın

Tahmin edilmiş kullanıcı yerine sağlayıcının başlangıç hesabını veya oluşturduğunuz yöneticiyi kullanın. Debug çıktısında hangi anahtar parmak izinin sunulduğunu bulun. Agent üzerinden gereksiz anahtar tekliflerini azaltmak için bilgisayarınızda şu denemeyi yapın.

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

Yapılandırılmış IdentityFile kayıtları yine uygulanabilir; ssh -G çıktısını inceleyin. Anahtar okunamıyorsa veya özel dosyanın izinleri fazla genişse sunucuyu değiştirmeden yerel dosyayı düzeltin.

Sunucuda hedef hesabın ev dizinini ve yetkili genel anahtarlarını kontrol edin. Örnek /home/ubuntu varsayar; getent sonucundaki gerçek dizini kullanın.

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

Sunulan parmak izini yetkili kayıtlarla karşılaştırın. Günlüklerde sahiplik, izin ve hesap politikası hatalarını inceleyin. AuthorizedKeysFile, dahil edilen dosyalar, Match kuralları veya sağlayıcının anahtar servisi varsayılan yolu değiştirebilir. Mevcut anahtarları koruyun; StrictModes kapatıp parola açarak nedeni gizlemeyin.

Değişen sunucu kimliğini güvenilir yoldan doğrulayın

Yeniden kurulum veya yeniden atanan IP anahtarı değiştirebilir; beklenmeyen değişiklik yanlış uç nokta veya araya girme işareti de olabilir. Kimliği doğrulanmış panelde VM kimliğini ve planlanan yeniden kurulumu kontrol edin.

Güvenilir konuk konsolunda istemcideki algoritmaya ait genel sunucu anahtarını inceleyin. Ed25519 için:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

SHA256 değerini istemci uyarısıyla karşılaştırın. Bu, kullanıcı giriş anahtarı veya sağlayıcı konsol gateway anahtarı değildir. Değişiklik doğrulanırsa önce known_hosts yedeğini alın ve yalnızca bu sunucunun kaydını güncelleyin. Bütün dosyayı silmeyin veya kontrolü atlamayın. Kimlik açıklanamıyorsa bağlantıyı durdurun.

Düzeltmeyi yeni oturumla doğrulayın

Belirlenen adresi, hesabı, anahtarı, dar ağ kuralını veya yapılandırma hatasını düzeltin. Sunucu değişirken bağımsız erişimi koruyun ve SSH yapılandırmasını uygulamadan önce denetleyin. Port değişikliği socket activation ayarlarını da ilgilendirebilir.

İlk denemeyi bağlantı paylaşımı kapalı olarak tekrarlayın. Yeni girişin doğru hesaba ulaştığını ve gereken sudo yetkisinin çalıştığını doğrulayın. Eski oturumun bağlı kalması bu test değildir. Hata ve düzeltmeyi kaydedip kurulum rehberine dönebilirsiniz.

Sorular ve yanıtlar