Wyjąć klucz buforowy do 192.168.1.123 w maszynie lokalnej:

ssh-keygen -R 192.168.1.123

W moim przypadku ssh-keygen -R ... nie naprawił tego ostrzeżenia. Miałem dodatkowe informacje jak:

Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24

Po prostu ręcznie edytowałem ~/.ssh/known_hosts i usuwałem linię 8 (“obraźliwy klucz”). Próbowałem połączyć się ponownie, host został dodany na stałe, a po tym wszystko było w porządku!

Robię wiele ssh-ing wokół między moimi komputerami w sieci LAN i moich dwóch kont hostingowych, więc mam uporządkowane wszelkiego rodzaju kursów i kończy się na SSH, w tym problemy z uwierzytelnianiem za pomocą ssh -v, aby zobaczyć, gdzie i co poszło nie tak.

Po prostu rozwiązał ten problem i nie jest zadowolony z odpowiedzi, chciałem naprawdę wiedzieć “dlaczego” siebie…

Wyzwalaczem w moim przypadku jest: zainstalowany nowy system operacyjny serwera w pracy i po zainstalowaniu pakietu openssh-server, nowy zestaw kluczy hosta zostały wygenerowane na serwerze pracy. Wcześniej wszystkie moje systemy operacyjne były Ubuntu i tym razem zmieniły się na Debiana (podejrzewam, że jest różnica w uprawnieniach).

Kiedy wszystkie systemy operacyjne były Ubuntu i ponownie instaluję system operacyjny serwera, po pierwszym wejściu SSH do niego otrzymuję tego typu ostrzeżenie, które wolę od cichego ostrzeżenia powyżej!

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

Wtedy otwieram ~/. ssh/known_hosts na komputerze inicjującym ssh, usuń tę linię, połącz się ponownie i tak się dzieje:

chris@home ~ $ ssh work
The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64

Ten bit o :11122 jest numerem portu, z którego kieruję SSH na firewallu

Sprawdziłem kopie zapasowe z poprzedniego serwera Ubuntu i diff’d na mojej nowej instalacji Debiana:

Ubuntu: Debian:
# Package generated configuration file # Package generated configuration file
# See the sshd(8) manpage for details # See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for # What ports, IPs and protocols we listen for
Port 22 Port 22
# Use these options to restrict which interface # Use these options to restrict which interfaces
#ListenAddress :: #ListenAddress ::
#ListenAddress 0.0.0.0 #ListenAddress 0.0.0.0
Protocol 2 Protocol 2
# HostKeys for protocol version 2 # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_dsa_key
------------------------------------------------ HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security #Privilege Separation is turned on for security
UsePrivilegeSeparation yes UsePrivilegeSeparation yes

Więc tak, prawdopodobnie host zaczął używać kluczy ecdsa ostatnio, co w oparciu o zmiany wprowadzone ostatnio przez Ubuntu, byłoby winą za aktualizację. Odejście Ubuntu od solidnego linuksa, na który liczyłem, jest powodem, dla którego tym razem zainstalowałem Debiana.

Przeczytałem security.SE q/a on ecdsa i już usunąłem tę linię z sshd_config mojego nowego serwera Debiana. (i uruchomiłem service ssh restart)

Zapytanie pojawia się za każdym razem, ponieważ adresy IP zmieniają się cały czas podczas korzystania z dynamicznego adresowania. Spróbuj użyć statycznego adresu IP, aby dodać klucz tylko raz.

ssh-keygen -f “/root/.ssh/known_hosts” -R 192.168.1.123

To powinno zastąpić istniejące klucze pod znanym_hosts.old i stworzyć nowy. To rozwiązanie zadziałało dla mnie w tym samym scenariuszu

Dodałem następujące linie do mojego ~/.ssh/config, wyłączając tym samym ścisłe sprawdzanie hosta dla wszystkich lokalnych adresów .eu. (z alokacją adresów DHCP, adresy ip moich lokalnych maszyn zawsze się zmieniają)

host *.local
    StrictHostKeyChecking no

Nadal jednak otrzymujesz ostrzeżenie, co jest w porządku przeze mnie.

Czy używasz tego samego użytkownika do połączenia?

Jeśli jesteś zalogowany do lokalnego komputera jak użytkownik Jane i połączyłeś się z serwerem B jak użytkownik Adolf@B i wszystko jest OK, nie oznacza to, że wszystko jest OK, jeśli jesteś zalogowany do lokalnego komputera jak użytkownik Jane i połączyłeś się z serwerem B jak użytkownik Adolf@B.

Jeśli chcesz zalogować się na serwerze B jako użytkownik Beda z PC A bez hasła, spróbuj tej komendy, wszystkie z PC A:

ssh-keygen -t rsa

Ta komenda generuje klucz i przechowuje go w pliku. Proszę pozostawić passphrase puste.

ssh Beda@B mkdir -p .ssh

To polecenie tworzy katalog, jeśli jeszcze nie istnieje. W przeciwnym razie nie należy drukować komunikatu o błędzie.

cd ~/.ssh

Polecenie to zmienia katalog na katalog domowy użytkownika ./ssh.

cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'

Polecenie to drukuje plik id_rsa. pub (twój klucz publiczny) na autoryzowane klucze na serwerze.

WAŻNE: Beda to twoja nazwa użytkownika na serwerze, z którym się łączysz, B to twój IP serwera.

Teraz możesz połączyć się z serwerem B bez hasła lub frazy hasła:

ssh Beda@B

Pytanie: Co jest tego przyczyną, …?

Więc klucz hosta serwera ssh zmienił się.  Co spowodowało tę zmianę?   Trudno powiedzieć.  Oto kilka zgadywanek:

• Czy sshd na myserverze zaczął używać kluczy ECDSA, więc jest to nowy typ klucza?
• Czy myserver został ostatnio ponownie zainstalowany?
• Czy sshd na myserverze został ostatnio ponownie zainstalowany, więc wygenerowany został nowy klucz hosta ssh?
• Czy ktoś ponownie wygenerował lub wymienił klucz hosta sshd?
• Czy adres IP serwera zmienił się tak, że inny host odpowiada na ten adres IP?

Pytanie: … i jak to naprawić?

Jak inni już odpowiedzieli, usuń z pamięci podręcznej klucz hosta ECDSA dla myservera, który Twoje konto zostało zbuforowane.

Wątek tutaj może pomóc.

Zasadniczo, chcesz usunąć oba klucze RSA i ECDSA dla tego hosta, a następnie użyć ssh-keyscan, aby umieścić je z powrotem do pliku known_hosts w sposób, który nie spowoduje tego konfliktu. Zadziałało to dla mnie, gdy miałem ten sam problem.

Ten błąd wciąż mnie denerwował przez długi czas. Z jakiegoś powodu zrobił mi różnicę czy zrobię

ssh host

czy

ssh host.domain

https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh

następnie wskazał mi opcję zmiany pliku konfiguracyjnego. Zobacz tam mój skrypt https://askubuntu.com/a/949731/129227 aby zautomatyzować proces.

Naprawiłem to na Chromebook'u poprzez odinstalowanie i ponowne zainstalowanie Secure Shell… To działało jak urok.

U mojego boku dzieje się to z powodu czegoś, co uważam za błąd ssh nowszych (od OpenSSH_7.9p1) klientów, kiedy próbuje nauczyć się bardziej bezpiecznego klucza serwera ecdsa, gdzie jest już znany starszy klucz typu rsa. Następnie przedstawia ten mylący komunikat!

Nie znam dobrej poprawki do tego, jedyne obejście jakie znalazłem to usunięcie wszystkich “dobrych ale starych kluczy rsa” tak, aby klient mógł ponownie nauczyć się “nowych bezpieczniejszych kluczy ecdsa”. Tak więc:

1. Pierwszym krokiem jest usunięcie wszystkich starych, dobrych kluczy RSA ( Ostrzeżenie! To traci ochronę przed MitM ):

2. Drugim krokiem jest ponowne nauczenie się wszystkich kluczy hosta, co należy zrobić ręcznie, łącząc się z każdym IP ponownie za pomocą ssh.

• *

Oto co obserwuję:

$ sftp test@136.243.197.100
Connected to test@136.243.197.100
sftp> 

$ sftp test@valentin.hilbig.de
Connected to test@valentin.hilbig.de.
sftp>

Teraz spróbuj połączyć się z nowo wprowadzonym aliasem tego samego już znanego dobrego serwera:

$ sftp test@gcopy.net
Warning: the ECDSA host key for 'gcopy.net' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:44
Are you sure you want to continue connecting (yes/no)?

Proszę spojrzeć na adres IP. Jest to ten sam adres IP co powyżej! Więc wygląda na to, że (dobry) klucz (znany) IP nagle się obraża (nie jest, ponieważ klient ssh miesza dwa niekompatybilne klucze, patrz poniżej).

Teraz spróbujmy to naprawić:

$ ssh-keygen -R 136.243.197.100
# Host 136.243.197.100 found: line 45
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

Spróbujmy jeszcze raz:

$ sftp test@gcopy.net
Warning: Permanently added the ECDSA host key for IP address '136.243.197.100' to the list of known hosts.
Connected to test@gcopy.net.

$ sftp test@valentin.hilbig.de
Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10
Are you sure you want to continue connecting (yes/no)?

WTF? Co tu się stało? Nowy, świeży klucz wyuczony z serwera znowu uległ awarii? A problem nawet zmienił strony?!?

Nie, to nie jest ani klucz, ani serwer. Wszystko jest prawidłowe!

To klient ssh, który nie zweryfikował prawidłowego klucza! Wpis 45 w known_hosts teraz nosi klucz typu ecdsa-sha2-nistp256, podczas gdy klucz, który został wyciągnięty z serwera przez klienta, jest typu rsa-sha2-512 (i dlatego nie może pasować do drugiego klucza!).

$ sftp -v test@valentin.hilbig.de

pokazuje:

debug1: kex: host key algorithm: rsa-sha2-512

podczas

$ sftp -v test@gcopy.net

pokazuje:

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

Najwyraźniej klient ssh ma gdzieś błąd! To nie może poradzić sobie z kluczem hosta istniejącego w więcej niż jednym wariancie! Albo wpada w pułapkę, aby zażądać przestarzałego wariantu klucza.

Jak naprawić?

Naprawdę nie mam pojęcia. To prawdopodobnie można naprawić tylko w górę rzeki.

Ale jest ręczna, ale niezdarna robota:

Trzeba ręcznie usunąć wszystkie ślady starego klucza typu rsa. Klucz, o którym mowa jest pokazany na wyjściu, ale nie jest bezpośrednio oznaczony jako problem:

Warning: the RSA host key for 'valentin.hilbig.de' differs from the key for the IP address '136.243.197.100'
Offending key for IP in /home/test/.ssh/known_hosts:45
Matching host key in /home/test/.ssh/known_hosts:10

check:

awk 'NR==45 { print $2 }' /home/test/.ssh/known_hosts
awk 'NR==10 { print $2 }' /home/test/.ssh/known_hosts

daje

ecdsa-sha2-nistp256
ssh-rsa

Więc tutaj dopasowany klucz hosta jest tym obraźliwym, a klucz obraźliwy jest tym właściwym, który musi być zachowany! Więc usuńmy ten niewłaściwy (pasujący):

ssh-keygen -R valentin.hilbig.de
# Host valentin.hilbig.de found: line 10
/home/test/.ssh/known_hosts updated.
Original contents retained as /home/test/.ssh/known_hosts.old

Teraz sprawdźmy jeszcze raz:

$ sftp test@valentin.hilbig.de
The authenticity of host 'valentin.hilbig.de (136.243.197.100)' can't be established.
ECDSA key fingerprint is SHA256:tf7lwe10C2p1lK2UG9p//m/4sUBCpX+i9k5Ub63c6Os.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'valentin.hilbig.de' (ECDSA) to the list of known hosts.
Connected to test@valentin.hilbig.de.
sftp> 

$ sftp test@gcopy.net
Connected to test@gcopy.net.
sftp> 

sftp test@136.243.197.100
Connected to test@136.243.197.100.
sftp>

YAY! Problem w końcu zniknął. Ale z kilkoma 100 wpisami w .ssh/known_hosts, to “rozwiązanie” naprawdę staje się poważnym PITA (i Error Prone Security Nightmare na Elm Street. YMMV).

Oto jak usunąć znany odcisk palca hosta (z pliku known_hosts) w systemie operacyjnym Chrome:

Znajdź indeks obraźliwego wpisu hosta na wyjściu ssh, gdy połączenie zawiedzie. Przykładowo w wierszu poniżej indeks obraźliwego hosta to 7 :

Offending ECDSA key in /.ssh/known_hosts:7

Otwórz konsolę JavaScript (CTRL+Shift+J) okna Secure Shell i wpisz następującą wartość, zastępując INDEX odpowiednią wartością (np. 7 ):

term_.command.removeKnownHostByIndex(INDEX);

To rozwiązanie zostało zapożyczone z Leo Gaggl’s Blog .