Üniversitedeki yurt odamda bazı kritik olmayan Ubuntu sunucuları çalıştırıyorum. Moladan önce onları kapattı, geri dön, SSH içeri girdi ve ECDSA anahtarlarının değiştiğine dair bir uyarı alın.
Neredeyse böyle görünüyordu
Warning: the ECDSA Host key for '<snip>' differs from the key for the IP address '<snip>'
Offending key for IP in /home/<snip>/.ssh/known_hosts:14
Matching Host key in /home/<snip>/.ssh/known_hosts:12
Are you sure you want to continue connecting (yes/no)?
Bu sunucu kimliği değişti hata çok daha az korkutucu görünüyor bu yüzden çok fazla endişelenmiyorum ama yine de, bu değişmesine neden olur? Bu endişe etmem gereken bir şey mi?
Belirli bir SSH sunucusuna ilk kez bağlandığınızda, normal soru anahtar parmak iziyle elde edilir; daha sonra SSH istemcisi sunucu ortak anahtarının bir kopyasını .ssh/known_hosts
dosyasında saklar. Ancak SSH istemcisi aslında depolar iki anahtar: biri sunucu için ad ve bir sunucu için [~ # ~] ip [~ # ~ ].
Örneğin, foo.example.com
Sunucusunun IP 10.0.0.8
Olduğunu varsayalım. İlk bağlantınız üzerine (ssh foo.example.com
), SSH istemcisi sunucu ortak anahtarını alacak, parmak izini (ortak anahtarın karması) gösterecek, onay isteyecek ve ardından known_hosts
biri foo.example.com
için, diğeri 10.0.0.8
için olmak üzere, her ikisi de aynı ortak anahtara işaret eden iki eşleme dosyası oluşturun.
Aynı sunucuya tekrar bağlandığınızda, SSH iki eşlemeyi doğrular. İlk eşleme (ad için olanı) known_hosts
'Da kaydedilenden farklı bir ortak anahtar verirse, ÜST HARFLER ile korkunç hata mesajı alırsınız (bu korkutucu olmayı başarır) ve istemci daha fazla bağlanmayı reddeder (bu nedenle mesaj sadece korkutucu değildir, aynı zamanda oldukça zahmetlidir).
Başka bir durum, ilk eşlemenin eşleşmesidir:
ssh foo.example.com
.10.0.0.8
Olarak çözer..ssh/known_hosts
Girişi altındaki foo.example.com
İle bulunan anahtarla eşleşir..ssh/known_hosts
Girişindeki 10.0.0.8
.Bu durumda, sorunuzda görüntülediğiniz iletiyi alırsınız. SSH istemcisi, hedeflenen sunucuyla konuştuğunuz konusunda bazı güvencelere sahiptir - ortak anahtar, aynı sunucu için kaydedilenle eşleşir ad - ancak bir şey hala yanlış, bu nedenle uyarı ve Onay İstemi.
Bu, sunucu IP'si değiştiğinde olabilir. Yukarıdaki örnekte, geçen hafta foo.example.com
IP'sinin 10.0.0.7
Olduğunu, ancak bar.example.com
IP'sinin 10.0.0.8
Olduğunu varsayalım. O zaman, ikisine de bağlandın. Ancak geçen hafta sonunda, hafif obsesif kompulsif bozukluğu olan bir sistem yöneticisi, bazı IP'lerin değiştirilmesine karar verdi, böylece daha verimli, düzenli ve matematiksel olarak zarif ağ kuralları kurabildi. Böylece sunucuları "hareket ettirdi" ve bar.example.com
Ayarını IP 10.0.0.16
Ve foo.example.com
Olarak 10.0.0.8
Olarak ayarladı. Arkadaşımız sysadmin, yeni IP'yi bildirmek için DNS'yi dürüstçe yapılandırdı. Şimdi Pazartesi günü, tekrar bağlanmak istiyorsunuz. SSH istemciniz DNS ile konuşuyor, foo.example.com
İçin yeni IP alıyor ve her şey yolunda, hariç10.0.0.8
İçin kaydedilen anahtarın foo.example.com
genel anahtarı: gerçekten de, known_hosts
dosyanız, bar.example.com
adlı IP'nin 10.0.0.8
altında listelenen genel anahtarının bir kopyasını içerir. geçen hafta, bar
adlı kişinin IP değil, foo
adlı kullanıcının IP'si.
OKB'li bir sisadmin bu senaryo için kesinlikle gerekli değildir; dinamik IP kurulumlarında veya bazı yük dengeleme durumlarında da olabilir.
Çözüm: bir metin düzenleyici kullanın ve rahatsız edici girişi known_hosts
Öğenizden kaldırın (sizin durumunuzda 14. satır). Belirli bir girişi kaldırmak için ssh-keygen -R <Host>
Komutunu da kullanabilirsiniz. Bir daha bağlanacağınız zaman, istemci başka bir uyarı daha gösterecektir (bu kez hedef IP için kaydedilmiş herhangi bir ortak anahtarın yokluk şikayet ediyor, ancak bu neredeyse fark edilmeden uçacak, çünkü hiç İstemi olmayacak. SSH istemcisi daha sonra ortak anahtarı known_hosts
İçine tekrar kaydeder ve en azından sysadmin sesleri duyana kadar doğru ayarlayacaktır tekrar.
Alternatif olarak, CheckHostIP
seçeneğini no
(sistem genelinde /etc/ssh/ssh_config
Veya .ssh/config
Olarak ayarlayarak SSH istemcisinde Ana Bilgisayar IP kontrolünü devre dışı bırakın, veya doğrudan komut satırında: ssh -o CheckHostIP=no foo.example.com
). Ana bilgisayar-IP denetimleri, sunucu adlarını gezerken görülen anormal durumları algılamak için yararlıdır, ancak bazı sistem yöneticileri için sunucu IP hokkabazlığı mükemmel "normal" dir.
<snip>
bölümlerini doğru tahmin ettiğimi varsayarsak, ana makine adı (example.com
) artık eskisinden farklı bir IP'ye çözümleniyor gibi görünüyor.
Bu konuda endişelenmeniz gerekip gerekmediği daha fazla bilgi olmadan söylemek zordur. Ana bilgisayar adı ne biçimdir? Bu bir FQDN mi? DNS kullanılarak çözüldü mü? DNS değişikliği yaptınız mı? Bu tür bilgiler.
Ana makine adlarınızı ve IP'lerinizi örneklerle değiştirmeniz daha iyidir (example.com
, example.net
, example.org
ve anything-you-want.test
, ana makine adları için iyidir, özel 192.168.foo.bar
veya 10.foo.bar.baz
gibi IP'ler IP'ler için iyidir), böylece komut çıkışının yorumlanması daha kolaydır. Bunu, iki alan adının aynı TLD'de olup olmadığını, iki IP'nin aynı alt ağda olup olmadığını belirtmek için de kullanabilirsiniz.
IP taşınmamışsa ve openssh-server paketi yükseltilmemişse ve yeni bir Host anahtarı oluşturulmuşsa, ne oldu?
Ana bilgisayar anahtarı denetimini devre dışı bırakabilirsiniz, ancak bu benim başlatacağım bir uygulama değil.
Olan şey şudur ki ssh şimdi farklı bir Host anahtar sistemi (ECDSA vs DSA veya RSA) kullanıyor ve uyarı bizi bunun farkında kılıyor.