Jest to prosty problem, z którym wszyscy się spotykamy i prawdopodobnie rozwiązujemy go ręcznie bez zastanowienia.
Gdy serwery się zmieniają, są ponownie przydzielane lub adresy IP są ponownie przydzielane, otrzymujemy poniżej komunikat weryfikacyjny hosta SSH. Jestem zainteresowany usprawnieniem przepływu pracy w celu rozwiązania tych błędów identyfikacji ssh.
Biorąc pod uwagę następujący komunikat, zazwyczaj vi /root/.ssh/known_hosts +434
usuwam ( dd
) linię naruszającą.
Widziałem, że programiści / użytkownicy innych organizacji usuwają cały swój known_hosts
plik z frustracji widząc tę wiadomość. Chociaż nie posuwam się tak daleko, wiem, że istnieje bardziej elegancki sposób, aby sobie z tym poradzić.
Napiwki?
[root@xt ~]# ssh las-db1
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
ed:86:a2:c4:cd:9b:c5:7a:b1:2b:cc:42:15:76:8c:56.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:434
RSA host key for las-db1 has changed and you have requested strict checking.
Host key verification failed.
linux
ssh
command-line-interface
ssh-keys
ewwhite
źródło
źródło
Odpowiedzi:
Możesz użyć
ssh-keygen
polecenia, aby usunąć określone wpisy według hosta:Jeśli nie masz tego polecenia, zawsze możesz użyć sed:
źródło
ssh-keygen
polecenie. Dobry!/etc/ssh/known_hosts
plik w sieci odpowiednimi kluczami hosta (zarządzanymi w / puppet itp.), lub wypełniasz swój osobisty plik ~ / .ssh / known_hosts (aby wykonać jeden z nich, możesz przejechaćssh-keyscan
przez znany dobry / bezpieczny połączenie). Blokowanie że (i zakładając, że w ogóle nie dbają o bezpieczeństwo) zbioruUserKnownHostsFile=/dev/null
orazStrictHostKeyChecking=no
w twoim~/.ssh/config file
(lub przejść do opcji ssh z-o
)Jako użytkownik marionetki moją metodą rozwiązania tego problemu jest fakt, że mój serwer marionetek zbiera klucze hosta SSH i publikuje je we wszystkich moich systemach, które wykonują połączenia SSH.
W ten sposób nie muszę się martwić o ich usunięcie. Dziewięćdziesiąt dziewięć procent czasu, w którym marionetka biegała i aktualizowała mi klucze, ponieważ mam agentów działających co trzydzieści minut. Wyjątki są dla mnie bardzo rzadkie, więc nie mam nic przeciwko szybkiej edycji znanych hostów w całym systemie, jeśli nie chcę czekać.
źródło
Chciałbym dodać sugestię, która może pomóc w bardzo szczególnych przypadkach, w których bezpieczeństwo ma mniejsze znaczenie.
Mam środowisko laboratoryjne z często instalowanymi maszynami. Za każdym razem, gdy to się dzieje, generowane są nowe klucze hosta (prawdopodobnie mógłbym gdzieś zapisać klucz hosta i ustawić go w skrypcie poinstalacyjnym).
Ponieważ bezpieczeństwo nie stanowi dla mnie problemu w tym środowisku laboratoryjnym, a klucze zmieniają się tak często, w pliku .ssh / config mam następujące elementy:
Zapewnia to, że połączenie z moimi komputerami laboratoryjnymi nigdy więcej nie spowoduje tego błędu, a mój klient ssh po prostu połączy się bez sprawdzania klucza hosta.
Jest to coś, co powinieneś zrobić tylko wtedy, gdy bezpieczeństwo nie ma dla ciebie żadnego znaczenia, ponieważ stawia cię to w trudnej sytuacji do ataku typu man-in-the-middle.
źródło
Zgodnie z informacją o wersji openssh 5.6 nie musisz już używać kluczy hostów:
Ostrzeżenie : jak dotąd nie słyszałem o nikim, kto używałby tej funkcji w produkcji. Używaj na własne ryzyko (ale uważam, że programiści openssh są wystarczająco paranoiczni, aby nie wypuszczać takiej zabójczej funkcji bez wielu testów i audytu kodu).
źródło
SSHFP DNS ResourceRecord może pomóc w zależności od tego, ile twój klient ssh z niego korzysta. Przechowuj tam wszystkie odciski palców kluczy publicznych ssh wraz z nazwą hosta.
Wcześniej należy zaimplementować DNSSEC lub DNS przez SSL.
http://www.ietf.org/rfc/rfc4255.txt
FreeIPA.org obsługuje zarządzanie kluczami hosta i użytkownika, a także certyfikaty PKI. Automatycznie przesyła również rekordy DNS SSHFP po utworzeniu nowych kluczy.
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/host-keys.html
źródło