Die SSH-Kommunikation wird mit Public-Key-Kryptographie gesichert. Wenn sich ein Benutzer zum ersten Mal mit dem SSH-Client mit dem SSH-Server verbindet, speichert das SSH-Programm den öffentlichen Schlüssel des SSH-Servers im Home-Verzeichnis des Benutzers in einer Datei, known_hosts, in einem versteckten Ordner namens ~/.ssh/, wie im folgenden Screenshot gezeigt:
Anschließend vergleicht der ssh-Client immer dann, wenn er sich mit dem Server verbindet, den vom Server gesendeten öffentlichen Schlüssel mit dem öffentlichen Schlüssel des Servers, der in der Datei ~/.ssh/known_hosts gespeichert ist. Wenn der öffentliche Schlüssel nicht übereinstimmt, geht der Client davon aus, dass der Netzwerkverkehr gekapert wird oder der Server, zu dem die Verbindung hergestellt wird, nicht derselbe ist, und daher unterbricht der SSH-Client die Verbindung, wie hier gezeigt:
$ ssh [email protected] @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 3f:1b:f4:bd:c5:aa:c1:1f:bf:4e:2e:cf:53:fa:d8:59. Please contact your system administrator. Add correct host key in /home/admin/.ssh/known_hosts to get rid of this message. Offending key in /home/admin/.ssh/known_hosts:3 RSA host key for 192.168.12.12 has changed and you have requested strict checking. Host key verification failed.$
Es gibt mehrere mögliche Gründe, warum sich der Remote-Host-Schlüssel geändert hat. Ein Man-in-the-Middle-Angriff ist nur ein möglicher Grund. Andere mögliche Gründe sind:
- OpenSSH wurde auf dem entfernten Host neu installiert, aber aus irgendeinem Grund wurde der ursprüngliche Hostschlüssel nicht wiederhergestellt.
- Der Remote-Host wurde rechtmäßig durch einen anderen Computer ersetzt.
Es ist auch möglich, dass der Server aus legitimen Gründen neu formatiert oder der Serverschlüssel ersetzt wurde. Unter solchen Umständen muss der Benutzer seine ~/.ssh/known_hosts-Dateien aktualisieren, indem er die alten Schlüssel löscht, um sich beim Server anmelden zu können.
Wenn Sie sicher sind, dass dies harmlos ist, können Sie eine der beiden folgenden Methoden verwenden, um openSSH auszutricksen, damit Sie sich anmelden können. Aber seien Sie gewarnt, dass Sie anfällig für Man-in-the-Middle-Angriffe geworden sind.
Methode 1 – Entfernen Sie den Hostschlüssel aus der Datei ~/.ssh/known_hosts
Die erste Methode besteht darin, den entfernten Host aus der Datei ~/.ssh/known_hosts zu entfernen. Beachten Sie, dass die Warnmeldung Ihnen bereits die Zeilennummer in der known_hosts-Datei mitteilt, die dem Ziel-Remote-Host entspricht. Die anstößige Zeile im obigen Beispiel ist Zeile 3 („Offending key in /home/admin/.ssh/known_hosts:3“)
Sie können den folgenden Einzeiler verwenden, um diese eine Zeile (Zeile 3) aus der Datei zu entfernen.
$ sed -i 3d ~/.ssh/known_hosts
Beachten Sie, dass Sie bei der obigen Methode aufgefordert werden, den Fingerabdruck des Hostschlüssels zu bestätigen, wenn Sie ssh ausführen, um sich anzumelden.
Methode 2 – StrictHostKeyChecking deaktivieren
Die zweite Methode verwendet zwei openSSH-Parameter:
- StrictHostKeyChecking
- UserKnownHostsFile
Diese Methode trickst SSH aus, indem sie es so konfiguriert, dass es eine leere known_hosts-Datei verwendet und Sie NICHT auffordert, den Remote-Host-Identitätsschlüssel zu bestätigen.
$ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no [email protected] Warning: Permanently added '192.168.12.12' (RSA) to the list of known hosts. [email protected]'s password:
Der Parameter UserKnownHostsFile gibt die Datenbankdatei an, die zum Speichern der Benutzerhostschlüssel verwendet werden soll (Standard ist ~/.ssh/known_hosts). Die /dev/null-Datei ist eine spezielle Systemgerätedatei, die alles verwirft, was darauf geschrieben wurde, und wenn sie als Eingabedatei verwendet wird, sofort das Ende der Datei zurückgibt.
Durch die Konfiguration der Null-Gerätedatei als Hostschlüsseldatenbank wird SSH vorgetäuscht, dass der SSH-Client noch nie zuvor eine Verbindung zu einem SSH-Server hergestellt hat und daher niemals auf einen nicht übereinstimmenden Hostschlüssel stoßen wird. Der Parameter StrictHostKeyChecking gibt an, ob SSH automatisch neue Hostschlüssel zur Hostschlüssel-Datenbankdatei hinzufügt. Wenn Sie es auf no setzen, wird der Host-Schlüssel automatisch hinzugefügt, ohne Benutzerbestätigung, für alle erstmaligen Verbindungen. Aufgrund der Null-Schlüssel-Datenbankdatei werden alle Verbindungen zum ersten Mal für einen beliebigen SSH-Server-Host angezeigt. Daher wird der Hostschlüssel automatisch ohne Benutzerbestätigung zur Hostschlüsseldatenbank hinzugefügt. Das Schreiben des Schlüssels in die /dev/null-Datei verwirft den Schlüssel und meldet Erfolg.
Indem Sie die obigen 2 SSH-Optionen in der Befehlszeile angeben, können Sie die Überprüfung des Hostschlüssels für diese bestimmte SSH-Anmeldung umgehen. Wenn Sie die Überprüfung des Hostschlüssels dauerhaft umgehen möchten, müssen Sie dieselben Optionen in der SSH-Konfigurationsdatei angeben. Sie können die globale SSH-Konfigurationsdatei (/etc/ssh/ssh_config) bearbeiten, wenn Sie die Änderungen für alle Benutzer dauerhaft machen möchten.
Wenn Sie einen bestimmten Benutzer ansprechen möchten, ändern Sie die benutzerspezifische SSH-Konfigurationsdatei (~/.ssh/config). Die folgenden Anweisungen gelten für beide Dateien. Angenommen, Sie möchten die Schlüsselüberprüfung für ein bestimmtes Subnetz umgehen (192.168.0.0/24).
Fügen Sie die folgenden Zeilen am Anfang der SSH-Konfigurationsdatei hinzu.
Host 192.168.0.* StrictHostKeyChecking no UserKnownHostsFile=/dev/null
Beachten Sie, dass die Konfigurationsdatei eine Zeile wie Host * gefolgt von einem oder mehreren Parameter-Wert-Paaren enthalten sollte. Host * bedeutet, dass es mit jedem Host übereinstimmt. Im Wesentlichen sind die Parameter nach Host * die allgemeinen Standardeinstellungen. Da der erste übereinstimmende Wert für jeden SSH-Parameter verwendet wird, möchten Sie die hostspezifischen oder subnetzspezifischen Parameter am Anfang der Datei hinzufügen.
Als letztes Wort der Vorsicht, es sei denn, Sie wissen, was Sie tun, ist es wahrscheinlich am besten, die Schlüsselüberprüfung von Fall zu Fall zu umgehen, anstatt pauschale dauerhafte Änderungen an den SSH-Konfigurationsdateien vorzunehmen.