Bei mir geschieht dies aufgrund eines Fehlers, den ich als ssh-Fehler neuerer (OpenSSH_7.9p1 und höher) Clients betrachte, wenn versucht wird, einen sichereren ecdsa-Serverschlüssel zu lernen, wenn bereits ein älterer rsa-Typschlüssel bekannt ist. Er präsentiert dann diese irreführende Meldung!
Ich kenne keine gute Lösung dafür, die einzige Abhilfe, die ich gefunden habe, ist, alle “guten, aber alten rsa-Schlüssel” zu entfernen, so dass der Client die “neuen sichereren ecdsa-Schlüssel” neu lernen kann. Also:
Der erste Schritt besteht darin, alle guten alten RSA-Schlüssel zu entfernen ( Warnung! Dadurch verliert der Client den Schutz gegen MitM ):
Der zweite Schritt besteht dann darin, alle Host-Schlüssel neu einzulernen, was manuell durch erneutes Verbinden mit jeder IP unter Verwendung von ssh geschehen muss.
Hier ist, was ich beobachte:
$ 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>
Versuchen Sie nun, sich mit einem neu eingeführten Alias dieses gleichen bereits bekannten guten Servers zu verbinden:
$ 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)?
Bitte schauen Sie sich die IP-Adresse an. Es ist die gleiche IP wie oben! Es sieht also so aus, als würde sich der (gute) Schlüssel der (bekannten) IP plötzlich selbst beleidigen (das ist er nicht, da der Client ssh zwei inkompatible Schlüssel mischt, siehe unten).
Jetzt versuchen wir, das zu beheben:
$ 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
Versuchen wir es noch einmal:
$ 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? Was ist hier passiert? Der neue frische Schlüssel, der vom Server gelernt wurde, schlägt wieder fehl? Und das Problem hat sogar die Seiten gewechselt?!?
Nein, es ist weder der Schlüssel noch der Server. Alles ist korrekt!
Es ist der Client ssh, der den korrekten Schlüssel nicht verifiziert! Der Eintrag 45 in known_hosts trägt nun einen Schlüssel vom Typ ecdsa-sha2-nistp256, während der Schlüssel, den der Client vom Server gezogen hat, vom Typ rsa-sha2-512 ist (und daher nicht mit dem anderen Schlüssel übereinstimmen kann!).
$ sftp -v test@valentin.hilbig.de
zeigt:
debug1: kex: host key algorithm: rsa-sha2-512
, während
$ sftp -v test@gcopy.net
zeigt:
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
Anscheinend hat der Client ssh irgendwo einen Fehler! Er kann nicht mit einem Host-Schlüssel umgehen, der in mehr als einer Variante existiert! Oder er tappt in die Falle, eine veraltete Variante eines Schlüssels anzufordern.
How to fix?
Ich habe wirklich keine Ahnung. Das lässt sich wahrscheinlich nur stromaufwärts beheben.
Aber es gibt eine manuelle, aber ungeschickte Abhilfe:
Sie müssen alle Spuren des alten Schlüssels vom Typ rsa manuell entfernen. Der fragliche Schlüssel wird in der Ausgabe angezeigt, aber er ist nicht direkt als das Problem gekennzeichnet:
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
ergibt
ecdsa-sha2-nistp256
ssh-rsa
Hier ist also der übereinstimmende Host-Schlüssel der anstößige, und der anstößige Schlüssel ist der richtige, den es zu behalten gilt! Entfernen wir also den falschen (passenden):
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
Nun prüfen Sie noch einmal:
$ 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>
JA! Problem endlich weg. Aber mit mehreren 100 Einträgen in .ssh/known_hosts wird diese “Lösung” wirklich zu einem großen PITA (und zu einem fehleranfälligen Sicherheitsalptraum in der Elm Street. YMMV.)