Al mio fianco questo accade a causa di qualcosa che considero un bug ssh dei client più recenti (OpenSSH_7.9p1 e superiori), quando si cerca di imparare una chiave server ecdsa più sicura dove è già nota una chiave di tipo rsa più vecchia. Presenta quindi questo messaggio fuorviante!
Non conosco una buona soluzione per questo, l'unica soluzione che ho trovato è quella di rimuovere tutte le “buone ma vecchie chiavi rsa” in modo che il client possa ri-imparare le “nuove chiavi ecdsa più sicure”. Quindi:
Il primo passo è quello di rimuovere tutte le buone vecchie chiavi RSA ( Attenzione! Questo perde la protezione contro il MitM ):
Il secondo passo poi è quello di riapprendere tutte le chiavi host, che deve essere fatto manualmente collegandosi ad ogni IP di nuovo utilizzando ssh.
Ecco quello che osservo:
$ 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>
``` ```
$ 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)?
Ora provate a collegarvi ad un nuovo alias di questo stesso buon server già conosciuto:
$ 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
Si prega di dare un'occhiata all'indirizzo IP. È lo stesso IP di cui sopra! Quindi sembra che la (buona) chiave dell'IP (noto) sia improvvisamente offensiva (non lo è, in quanto il client ssh mescola due chiavi incompatibili, vedi sotto).
Ora proviamo a sistemarlo:
$ 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)?
``` ```
$ sftp -v test@valentin.hilbig.de
Proviamo di nuovo:
debug1: kex: host key algorithm: rsa-sha2-512
WTF? Cosa è successo qui? La nuova chiave nuova appresa dal server si guasta di nuovo? E il problema ha anche cambiato lato?
No, non è la chiave, né il server. Tutto è corretto!
È il client ssh che non riesce a verificare la chiave corretta! La voce 45 in known_hosts ora porta una chiave di tipo ecdsa-sha2-nistp256 mentre la chiave, che è stata estratta dal server dal client, è di tipo rsa-sha2-512 (e quindi non può corrispondere all'altra chiave!).
$ sftp -v test@gcopy.net
``` ```
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
mostra:
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
mentre
awk 'NR==45 { print $2 }' /home/test/.ssh/known_hosts
awk 'NR==10 { print $2 }' /home/test/.ssh/known_hosts
mostra:
ecdsa-sha2-nistp256
ssh-rsa
A quanto pare il client ssh ha un bug da qualche parte! Non è in grado di gestire una chiave host esistente in più di una variante! Oppure cade nella trappola di richiedere una variante obsoleta di una chiave.
Come risolvere?
Non ne ho davvero idea. Questo probabilmente può essere risolto solo a monte.
Ma c'è una soluzione manuale ma maldestra:
Bisogna rimuovere manualmente tutte le tracce della vecchia chiave del tipo rsa. La chiave in questione è mostrata nell'uscita, ma non è segnata direttamente come il problema:
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
controllo:
$ 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>
dà
&001 &001
Quindi qui la chiave host matching è quella offensiva e la chiave offensiva è quella giusta che deve essere tenuta! Quindi togliamo quella sbagliata (corrispondente):
&001 &001
Ora ricontrolliamo:
&001 &001
YAY! Il problema è finalmente risolto. Ma con diverse 100 voci in .ssh/known_hosts, questa “soluzione” diventa davvero una grande PITA (e un Error Prone Security Nightmare su Elm Street. YMMV.)