SSH bağlantısında sunucu kimliğinin değiştiğini belirten uyarı gördüğünüzde amaç ekrana daha hızlı geçmek olmamalıdır. İstemci daha önce tanıdığı sunucuyla şimdi gördüğü kimlik arasında fark bulmuştur. Yeniden kurulum gibi meşru bir işlem de, yanlış hedefe bağlanma gibi incelenmesi gereken bir durum da bunu açıklayabilir. Genel erişim ve hesap koruması için VDS güvenlik kontrol listesi iyi bir başlangıçtır.
Değişikliğin zamanını ve hedefini kontrol edin
Son bağlantıdan beri işletim sistemi yeniden kuruldu mu, IP başka sunucuya atandı mı, alan adının hedefi değişti mi? Bu soruların yanıtını yönetim kaydından bulun. Tarayıcıda eski bir panel açık diye yeni SSH hedefinin aynı olduğunu varsaymayın. Kullanıcı adını, hedef adı, portu ve hata zamanını kaydedin; bağlantı parolasını veya özel anahtar içeriğini destek kaydına eklemeyin.
Saklanan anahtarın ne olduğunu okuyun
OpenSSH ssh-keygen belgesi, bilinen sunucu kaydını aramak için -F ve anahtar parmak izini göstermek için -l seçeneklerini tanımlar. Örneğin ssh-keygen -F sunucu.example ilgili kayıtları incelemek içindir. Standart dışı port kullanılıyorsa kayıt adı portu da içerebilir. Bu aşamada dosyayı silmeyin veya sunucu kimlik kontrolünü kapatan seçenekler eklemeyin.
Bir yönetici sunucu konsolundan gerçek host anahtarının parmak izini gösterebilir. Gelen parmak izini önceden güven duyduğunuz panel, konsol veya doğrulanmış destek kanalı üzerinden karşılaştırın. Aynı şüpheli bağlantı içinden alınan bir bilgi bağımsız teyit yerine geçmez. Uyarıyı kopyalarken anahtar türünü ve SHA256 parmak izini korumak karşılaştırmayı kolaylaştırır.
Doğrulamadan sonra kayıt güncelleme kararı
Beklenen değişiklik belgelenmiş ve yeni kimlik doğrulanmışsa yalnız ilgili kaydın güncellenmesi planlanabilir. Eski dosyanın güvenli kopyasını koruyun; tüm known_hosts dosyasını boşaltmak gerekli değildir. Değişiklik açıklanamıyorsa bağlantıya devam etmeyin. Kullanıcı parolasını tekrar tekrar denemek bu güven sorununu çözmez. Dosya aktarımına geçmeden SFTP bağlantı rehberindeki hedef ve protokol ayrımını da kontrol edin.
Bir sonraki yeniden kurulum için kayıt tutun
Sunucu adı, hizmet kimliği, kullanılan SSH portu, host anahtarı türü ve doğrulanmış parmak izi gibi bilgileri yetkili ekip içinde saklayın. Anahtarın özel kısmını envantere koymayın. SSH iki faktörlü doğrulama kullanıcı hesabını güçlendirir; sunucunun kimliğini doğrulama ihtiyacını ortadan kaldırmaz. Aynı şekilde VDS paketinin işlemcisi veya RAM’i bu uyarının güvenli biçimde aşılmasıyla ilgili değildir.
Destek isterken hangi değişikliğin yapıldığını ve yeni parmak izini hangi kanaldan doğruladığınızı yazın. Planlı yeniden kurulumlarda bu bilginin önceden hazırlanması gereksiz paniği azaltır. Açıklanamayan bir farkta ise acele etmek yerine doğru sunucuya bağlandığınızın kanıtını beklemek daha güvenli yaklaşımdır.
Kurulum işlemini başka biri yaptıysa değişiklik notunu yalnız sözlü olarak almayın; yetkili iş kaydıyla eşleştirin. Yeniden kurulum tarihi, hedef hizmet ve yeni kimliğin doğrulandığı kanal aynı kayıtta bulunmalıdır. Bu disiplin, sonraki ekip üyesinin eski uyarıyı otomatik olarak kabul etmesini önler ve planlı değişiklik ile açıklanamayan kimlik farkının ayrı ele alınmasını sağlar.
Sıkça Sorulan Sorular
Sunucuyu yeniden kurdum, uyarı normal mi?
Yeniden kurulum anahtar değişikliğini açıklayabilir; yine de yeni parmak izini konsol veya güvenilir yönetim kanalından doğrulayın.
known_hosts dosyasını tamamen silmeli miyim?
Hayır. Bu, diğer sunucular için saklanan güven ilişkisini de kaybettirir; önce yalnız ilgili kaydı ve değişikliği inceleyin.
ssh-keyscan tek başına kimlik kanıtı mı?
Hayır. Ağdan alınan anahtar, bağımsız güvenilir bir kanalla doğrulanmadan kimlik kanıtı sayılmaz.
Bu kullanıcı özel anahtarımın değiştiği anlamına mı gelir?
Hayır. Sunucunun host anahtarı ile sizin oturum açarken kullandığınız kullanıcı anahtarı farklıdır.