Problem z połączeniem SSH z błędem „Nieudana weryfikacja klucza hosta…”

Mogę połączyć się z innym komputerem Ubuntu w mojej sieci LAN przez SSH. Na obu komputerach zainstalowałem openssh-server, ale z innego komputera Ubuntu nie mogę połączyć się z komputerem przez SSH i dostałem ten błąd:

Weryfikacja klucza hosta nie powiodła się ...

„Host weryfikacja klucza nie powiodło się” oznacza, że gospodarz klucz zdalnego hosta została zmieniona.

SSH przechowuje klucze hostów hostów zdalnych w ~/.ssh/known_hosts. Możesz albo edytować ten plik tekstowy ręcznie i usunąć stary klucz (możesz zobaczyć numer linii w komunikacie o błędzie), albo użyć

ssh-keygen -R hostname

Ze strony podręcznika :

-R
nazwa hosta Usuwa wszystkie klucze należące do nazwy hosta ze znanego pliku hosta. Ta opcja jest przydatna do usuwania zakodowanych hostów.

(czego dowiedziałem się z odpowiedzi na pytanie Czy można usunąć określony klucz hosta z pliku znanego_hosta SSH? ).

Jeśli działasz w pewnych sytuacjach zdalnych / skryptowych, w których nie masz interaktywnego dostępu do klucza zachęty do dodania hosta, obejdź go w ten sposób:

$ ssh -o StrictHostKeyChecking=no user@something.example.com uptime

Ostrzeżenie: na stałe dodano „coś.example.com, 10.11.12.13” (RSA) do listy znanych hostów.

Czasami zdarza się również sytuacja, gdy pracujesz na konsoli szeregowej, a następnie sprawdzenie powyższego polecenia w trybie pełnym -vpokazuje, /dev/ttyże nie istnieje, podczas gdy on istnieje.

ssh -v user@hostname

W powyższym przypadku wystarczy usunąć /dev/ttyi utworzyć dowiązanie symboliczne /dev/ttyS0do /dev/tty.

rm /dev/tty
ln -s /dev/ttyS0 /dev/tty

Alternatywnie dodaj id_rsa.pubdo zdalnej lokalizacji, aby hasło nie było wyświetlane i uzyskasz dostęp do logowania.

W moim przypadku było to spowodowane problemem udev - nie było /dev/ttywęzła urządzenia. Rozwiązaniem było dla mnie tylko:

sudo mknod -m 666 /dev/tty c 5 0

Na terminalu:

ssh -o StrictHostKeyChecking=no -i YourPublicKey.pem user@example.com uptime

Pojawi się następujący komunikat lub podobny komunikat:

Warning: Permanently added 'example.com, XX.XXX.XXX.XX' (ECDSA) to the list of known hosts.
 00:47:37 up 3 min,  0 users,  load average: 0.00, 0.00, 0.00

Następnie podłącz do EC2 jak zwykle:

ssh -i YourPublickey.pem user@example.com

Po prostu dlatego, że drugie Ubuntu wymaga połączenia kluczem, a nie hasłem.

Proponuję używać sudo dpkg-reconfigure openssh-serverna komputerze, a następnie powinien działać poprawnie. Zresetuje konfigurację dla openssh i powróci do domyślnego uwierzytelnienia hasłem.

Druga możliwość polega na tym, że w twoim komputerze jest już klucz do twojego drugiego ubuntu i że zmienił się, nie będąc już rozpoznawany. W takim przypadku musisz edytować plik, .ssh/authorized_keysaby usunąć problematyczną linię identyfikującą Twoje Ubuntu.

To jest stary wątek i właśnie natknąłem się na tę odpowiedź, dodam tylko to, co zrobiłem, aby to rozwiązać.

ssh-keygen -f "/home/USER/.ssh/known_hosts" -R HOSTNAME

Właśnie spojrzałem na komunikat o błędzie, który mi rzucił, i powiedział, aby uruchomić to polecenie, aby usunąć go z listy hostów. Następnie wykonałem następujące czynności:

ssh-copy-id HOSTNAME

Następnie wykonałem polecenia z tego miejsca, dopóki nie mogłem ssh na serwerze.

Oznacza to, że klucz zdalnego hosta został zmieniony (może to być zmiana hasła hosta),

Twój terminal zaproponował wykonanie tego polecenia jako użytkownik root

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]:4231

Musisz usunąć tę nazwę hosta z listy hostów na komputerze / serwerze. Skopiuj sugerowane polecenie i wykonaj jako użytkownik root.

$ sudo su                                                            // Login as a root user

$ ssh-keygen -f "/root/.ssh/known_hosts" -R [www.website.net]:4231   // Terminal suggested command execute here
Host [www.website.net]:4231 found: line 16 type ECDSA
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

$ exit                                                               // Exist from root user

$ sudo ssh root@www.website.net -p 4231                              // Try again

Mam nadzieję, że to zadziała.

Powinieneś zmienić swój klucz w ten sposób: Na podstawie podanego błędu znajdź, który klucz hosta zmienił się, na przykład: Obrażanie klucza ECDSA w /Users/user-name/.ssh/known_hosts:5 powiedział, że 5. klucz został zmieniony, więc zrób to:

sed -i '5d' ~/.ssh/known_hosts

Uwaga: musisz być rootem lub mieć uprawnienia do sudo.

musisz umieścić klucz rsa hosta docelowego na hoście źródłowym /home/user/.ssh/known_hosts, uruchamiając go na celu

ssh-keyscan -t rsa @targethost

Być może po prostu musisz wpisać „tak”, gdy ssh potwierdzi, że chcesz kontynuować łączenie.

Jak poniżej.

The authenticity of host 'xxx' can't be established.
ECDSA key fingerprint is yyy.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'xxx' (ECDSA) to the list of known hosts.
Enter passphrase for key '/Users/ysy/.ssh/id_rsa':

Następnie wprowadź swoje hasło.

Proszę zwrócić uwagę na „Czy na pewno chcesz kontynuować łączenie (tak / nie)? Tak ”. Musisz wpisać tak, nie wchodzić.

Oprócz ścisłego wyłączania sprawdzania klucza hosta możesz także połączyć się, wpisując:

ssh -o LogLevel=quiet -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no <username@target_machine_ip_or_domain_name>

pico ~/.ssh/known_hosts i usuń wszystkie linie, po ponownym połączeniu, a otrzymasz nowy klucz.

Moje rozwiązanie pochodzi z tego postu na blogu: Negocjacja algorytmu dla klienta SSH Secure Shell nie powiodła się

Musisz zmodyfikować plik w następujący sposób:

sudo nano /etc/ssh/sshd_config

A następnie dodaj:

# Ciphers
Ciphers aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour
KexAlgorithms diffie-hellman-group1-sha1

Zasadniczo wypróbowałeś różne rozwiązania, aż znajdziesz takie, które może rozwiązać Twój problem. Jeśli powyższe rozwiązania nie działają, spróbuj tego. Jeśli ten nie działa tak dobrze, spróbuj innych.

Po prostu zrób „sudo vi /var/root/.ssh/known_hosts” i usuń linię, która zawiera klucz dla hosta, z którym próbujesz się połączyć i ponownie połączyć.

Nie wiem o Twojej konkretnej sytuacji, ale najprawdopodobniej ten błąd pojawił się wraz z następującym komunikatem:

my_mac:~ oivanche$ sudo ssh pi@192.168.0.45
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:sx1Z4xyGY9venBP6dIHAoBj0VhDOo7TUVCE2xWXpzQk.
Please contact your system administrator.
Add correct host key in /var/root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /var/root/.ssh/known_hosts:74
ECDSA host key for 192.168.0.45 has changed and you have requested strict checking.
Host key verification failed.

Jeśli przeczytasz dziennik uważniej, zobaczysz, że klucz, który otrzymałeś od hosta, jest w konflikcie z kluczem, który już masz - w tym przypadku znajduje się on w linii 74 pliku znanego_hosta (Obrażający klucz ECDSA w / var / root / .ssh / known_hosts: 74). Usuń wiersz ze znanych_hostów, zapisz zmiany i ponownie połącz.

chmod 666 /dev/tty 

jest jeszcze innym rozwiązaniem tty - czasami ten plik urządzenia ma złe uprawnienia.