SSH bağlantısı: ağ, host anahtarı ve kullanıcı yetkisini ayrı incelemek

SSH bağlantısı kurulamadığında görülen hata, incelemenin hangi katmandan başlaması gerektiğini gösterir. Ağ zaman aşımı, servisin dinlememesi ve kullanıcı doğrulama reddi farklı nedenlerdir. Güvenlik uyarısını kapatmak bu ayrımı yapmanın yerine geçmez.

1. Hata aşamasını bul
2. DNS ve portu sına
3. Sunucu servisini incele
4. Host kimliğini doğrula
5. Kullanıcı yetkisini kontrol et
6. Yeni oturumla kabul et

Tam hata mesajını ve kaynak yolunu kaydedin

VPN üzerinden erişim ile yerel ağ erişimi farklı rota kullanabilir. Kaynak cihaz, hedef adı, port ve deneme zamanı belirlenir. Connection refused ile timeout aynı kanıt değildir; biri hedef veya ara cihazın aktif reddini gösterebilir.

İstemci ayrıntılı çıktısı kimlik dosyası yolları ve kullanıcı bilgileri içerebilir. Destek paylaşımından önce hassas alanlar ayıklanır. Örnek hedef sunucu.batuhanyazici.com yalnızca laboratuvar adlandırmasıdır.

ssh -v labadmin@sunucu.batuhanyazici.com
# Sunucunun yetkili konsolundan:
systemctl status ssh --no-pager
sudo sshd -t

Sunucu ve ağ kontrolünü ayırın

Servis adı dağıtıma göre ssh veya sshd olabilir. Dinleyen port, yerel güvenlik duvarı ve ara ağ kuralı kontrol edilir. Konsolda sağlıklı servis görmek uzaktan kaynak için yolun açık olduğunu kanıtlamaz.

Yönetim erişimi yalnızca gerekli kaynaklara sınırlandırılır. Sorunu çözmek için bütün internete genel SSH izni veya root parola erişimi açmayın. NAT ve dönüş rotası varsa iki yönde değerlendirilir.

Host key değişimini kimlik doğrulama sorunu olarak ele alın

Sunucu yeniden kurulmuş veya anahtarı değiştirilmiş olabilir; yanlış hedef ya da araya girme riski de mümkündür. Yeni parmak izi bağımsız güvenilir kanaldan doğrulanmadan uyarı atlanmamalıdır.

Doğrulama tamamlandığında yalnızca ilgili known_hosts kaydı desteklenen araçla güncellenir. Bütün dosyayı silmek veya StrictHostKeyChecking’i kapatmak başka sunucuların kimlik korumasını da zayıflatır.

Kullanıcı ve anahtar yetkisini kontrol edin

Permission denied mesajında kabul edilen yöntemler, public key eşleşmesi, hesap durumu ve erişim politikası incelenir. Dosya sahipliği ve izinleri doğru olmalıdır. Özel anahtar sunucuya veya genel dokümana kopyalanmaz.

Merkezi kimlik, HBAC veya grup kısıtı varsa yerel kullanıcı ayarı tek başına yeterli olmayabilir. Aynı kullanıcının konsolda oturum açması SSH yönteminin de izinli olduğunu göstermez.

Mevcut erişimi koruyarak değişikliği kabul edin

sshd yapılandırması değiştirilecekse mevcut yönetim oturumu ve konsol yolu açık tutulur. Sözdizimi testi sonrası kontrollü reload uygulanır ve yeni oturumla doğrulama yapılır. İzinli giriş kadar yetkisiz yöntemin reddi de sınanır.

• Hata katmanı kesinleştirildi.
• Doğru hedef ve port doğrulandı.
• Host parmak izi bağımsız kontrol edildi.
• Kullanıcı ve anahtar kapsamı uygun.
• Yeni oturum ve olumsuz test başarılı.

İlgili çalışma notları

• Linux sudo yetkisi: grup üyeliği, komut kapsamı ve oturum doğrulaması
• ENS Linux kurulumu: çekirdek uyumluluğu ve gerçek koruma sağlığı
• Klon Linux sunucuda ağ gelmiyor: MAC, arayüz adı ve profil eşleşmesi

Nasıl yapılır: ayrıntılı uygulama

Ortam ve ön koşullar: Yazıda belirtilen ürün ve desteklenen pilot ortam — Yetkili izole pilot, belirtilen sürüm/model desteği, mevcut durum kaydı ve değişiklik gerekiyorsa tutarlı yedek/geri erişim gerekir.

1. Ad ve TCP yolunu sınayın
2. Host anahtarını güvenilir kanaldan doğrulayın
3. Ayrıntılı bağlantıyı doğru kullanıcıyla açın
4. Sunucuda config ve auth kaydını karşılaştırın
5. Oturumu koruyarak geri dönün

1. Ad ve TCP yolunu sınayın

Windows istemci örneğinde gerçek SSH portu farklıysa 22’yi değiştirin. TCP açılması kullanıcı yetkisini kanıtlamaz.

Resolve-DnsName ssh.batuhanyazici.com
Test-NetConnection ssh.batuhanyazici.com -Port 22

2. Host anahtarını güvenilir kanaldan doğrulayın

Sunucu yöneticisinin console/önceden güvenilir kaydından host-key fingerprint alın. ssh-keyscan yalnız görünen anahtarı toplar; kimliği doğrulamaz. Known_hosts satırını uyarıyı geçmek için körlemesine silmeyin.

3. Ayrıntılı bağlantıyı doğru kullanıcıyla açın

Özel anahtar yolunu Edit ile kendi güvenli yolunuza uyarlayın; anahtar içeriğini paylaşmayın. -v çıktısı özel kimlik/yol bilgisi içerebilir.

ssh -v -o IdentitiesOnly=yes -i ~/.ssh/batuhanyazici-lab batuhanyazici@ssh.batuhanyazici.com

4. Sunucuda config ve auth kaydını karşılaştırın

Yetkili konsolda daemon sözdizimi, listener, ilgili kullanıcı ve authentication log’unu inceleyin. Dağıtımda unit ssh/sshd adı değişebilir.

sudo sshd -t
sudo sshd -T | grep -E "^(port|pubkeyauthentication|passwordauthentication|permitrootlogin) "
sudo ss -lntp
sudo journalctl -u sshd --since "15 minutes ago" --no-pager

5. Oturumu koruyarak geri dönün

Config değişikliğinde mevcut yönetim oturumunu açık tutun; ikinci yeni bağlantı başarılı olmadan kapatmayın. Önceki sshd config/authorized_keys kapsamını kayıtla geri alın; StrictHostKeyChecking=no veya genel root/password erişimi açmayın.

Beklenen sonuç: Doğru host key ve kullanıcıyla yeni SSH oturumu açılır; geniş güven bypass’ı kullanılmaz.

Sonuç farklıysa: Başarısız aşamada durun; ilgili kayıt/ürün sürümü/ön koşulu inceleyin. Farklı katmanı genel olarak sıfırlamak yerine tek nedeni ayırın.

Geri dönüş: Yalnız bu işlemde değişen öğeyi önceki uyumlu sürüm veya açıkça belirtilen yedek/restore planıyla geri alın; geri alınamaz veri/disk işlemlerini ayar geri dönüşü sanmayın.