Beim Versuch, in einen von mir gesteuerten Computer zu sshen, erhalte ich die vertraute Nachricht:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 RSA key sent by the remote host is
[...].
Please contact your system administrator.
Add correct host key in /home/sward/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sward/.ssh/known_hosts:86
RSA host key for [...] has changed and you have requested strict checking.
Host key verification failed.
Ich habe in der Tat den Schlüssel geändert. Und ich habe ein paar Dutzend Postings gelesen, in denen gesagt wird, dass die Lösung dieses Problems darin besteht, den alten Schlüssel aus der known_hosts
Datei zu löschen .
Aber ich möchte, dass ssh sowohl den alten als auch den neuen Schlüssel akzeptiert. Die Sprache in der Fehlermeldung (" Add correct host key
") deutet darauf hin, dass es eine Möglichkeit geben sollte, den richtigen Hostschlüssel hinzuzufügen, ohne den alten zu entfernen.
Ich konnte nicht herausfinden, wie der neue Hostschlüssel hinzugefügt werden kann, ohne den alten zu entfernen.
Ist das möglich oder ist die Fehlermeldung nur extrem irreführend?
Antworten:
Holen Sie sich den RSA - Schlüssel des Servers, wo
server_ip
Ihre Server-IP - Adresse ist, wie zum Beispiel192.168.2.1
:Beispielantwort:
Kopieren Sie auf dem Client die gesamte Antwortzeile
server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
und fügen Sie den folgenden Schlüssel am Ende Ihrer~/.ssh/known_hosts
Datei hinzu:quelle
ssh-keyscan -t rsa1,dsa,rsa,ecdsa,ed25519 server_ip
- aber der einzige Grund zu findenrsa1
unddsa
ist Schlüssel - Server zu identifizieren , die aktualisiert / neu konfiguriert werden müssenEntfernen Sie den Eintrag von known_hosts mit:
Dadurch wird die problematische IP- Adresse oder der Hostname aus der Datei " known_hosts " entfernt und es wird erneut versucht, eine Verbindung herzustellen .
Aus den Manpages:
quelle
Ein sehr einfacher Weg ist:
Bearbeiten Sie anschließend known_hosts, um den ursprünglichen Schlüssel zu löschen, und senden Sie ssh an den Host. Verwenden Sie dazu Folgendes:
Der neue Schlüssel wird automatisch hinzugefügt. Vergleichen Sie dann die beiden Dateien. Ein Programm wie meld ist eine gute Möglichkeit, die beiden Dateien zu vergleichen. Führen Sie dann die Dateien zusammen, damit known_hosts beide Schlüssel enthält
Mein 'Grund' für die Beibehaltung von zwei Schlüsseln ist, dass das Zielsystem Multiboot ist, obwohl ich sagen kann, dass es eine Möglichkeit gibt, die Schlüssel in den Installationen zu synchronisieren, scheint es einfacher zu sein, mehrere Schlüssel zuzulassen.
EDIT 2015/06
Ich sollte noch einmal hinzufügen, dass ich es auf noch einfachere Weise bemerke [solange der Eintrag identifizierbar ist, normalerweise anhand des Hostnamens / der IP-Adresse, abgesehen von der Fehlermeldung, die auf den spezifischen Ort verweist].
Es gibt sogar die Option HostKeyAlias wie in
Anschließend können Sie, nachdem der ssh-Client den neuen Schlüssel unter dem Alias hinzugefügt hat, entweder known_hosts bearbeiten, um den Alias durch den "echten" Hostnamen / die IP-Adresse zu ersetzen, oder die Verbindung zu dieser Inkarnation des Hosts mit der Alias-Option immer wieder herstellen
quelle
Ich habe das gleiche Problem mit einer Himbeer-Pi, die ich mit mehreren verschiedenen Systemen (Dev-System zum Kompilieren von Arm-Binärdateien, Project, XBMC, etc.) boote und auf das gleiche Problem gestoßen bin. In einem lokalen Netzwerk wird DHCP verwendet, und mein Router hat immer dieselbe IP-Adresse verwendet, da die MAC-Adresse identisch war. Ich habe es gelöst, indem ich verschiedene Domainnamen in meiner Hosts-Datei verwendet habe:
Die Datei known_hosts speichert Fingerabdrücke nach Hostnamen, sodass jeder eindeutige Hostname einen anderen Eintrag erhält, obwohl es sich um dieselbe IP-Adresse handelt.
Jedes Mal, wenn ich ein neues System benutzte, hatte ich es satt, die Namen zu den Hosts-Dateien hinzuzufügen. Daher kam ich auf eine noch einfachere Art und Weise, indem ich führende Nullen für IP-Adressen verwendete, wie zum Beispiel:
Jede Variation der (nicht kanonisierten) IP-Adresse erhält einen eigenen Eintrag in known_hosts.
quelle
CheckHostIP no
in verwenden~/.ssh/config
, um das Schlupfloch noch nutzen zu können. Sie können dort sogar Ihre Aliase definieren, so dass Sie nicht nur für diese 3 Hostnamen fummeln/etc/hosts
und definieren müssenCheckHostIP no
.Wenn sowohl Ihr Client als auch Ihr Server über OpenSSH 6.8 oder höher verfügen, können Sie die
UpdateHostKeys yes
Option in Ihremssh_config
oder verwenden~/.ssh/config
. Zum Beispiel:Dadurch speichert SSH alle Hostschlüssel, die der Server benötigt
known_hosts
, und wenn ein Server einen Hostschlüssel ändert oder entfernt, wird der Schlüssel auch in Ihrem geändert oder entferntknown_hosts
.quelle
Ich verstehe nicht, warum Sie mit zwei Schlüsseln arbeiten möchten, aber Sie können der
~/.ssh/known_hosts
Datei sicherlich mehr als einen gültigen Schlüssel hinzufügen , müssen dies jedoch manuell tun.Eine andere Lösung könnte darin bestehen, die
StrictHostKeyChecking=no
Option für diesen bestimmten Host zu verwenden:welche du in einen alias in deinem
~/.profile
oder ähnlichem setzen könntest .quelle
Wenn Sie nur in ein lokales Netzwerk ssh dann ...
Eine einfache Lösung besteht darin, die alte Schlüsseldatei zu löschen und durch eine leere zu ersetzen. Auf diese Weise können Sie alle Verbindungen mit neuen Schlüsseln erneut autorisieren. Wenn Sie SSH-Schlüssel für Standorte außerhalb Ihres lokalen Netzwerks gespeichert haben, müssen Sie sicherstellen, dass Ihre ursprüngliche Verbindung so sicher ist, wie Sie es beim ersten Herstellen einer Verbindung mit diesem Server getan haben.
z.B
Drücken Sie dann die Leertaste, die Rücktaste Strg + x und 'y', um den neuen Puffer (Datei) zu speichern. Es ist eine schlechte Praxis, aber in Ordnung, vorausgesetzt, Sie ssh'n nicht regelmäßig außerhalb Ihres lokalen Netzwerks (z. B. einer Uni oder eines Arbeitsservers).
In einem sicheren lokalen Netzwerk ist dies sicher, da Sie einfach keinen Mann in den mittleren Angriff bringen können.
Es ist immer besser, Code zu verwenden, den Sie verstehen!
quelle
known_hosts
jedes Mal die gesamte Datei löschen, wird der größte Teil der sonst von ssh bereitgestellten Sicherheit zunichte gemacht.So viele Antworten, aber so viele, die den Schutz aufgeben, indem sie die strenge Host-Überprüfung vollständig deaktivieren oder nicht verwandte Host-Informationen zerstören oder den Benutzer nur dazu zwingen, Schlüssel interaktiv zu akzeptieren, möglicherweise zu einem späteren Zeitpunkt, wenn dies unerwartet ist.
Hier ist eine einfache Methode, mit der Sie die strenge Host-Überprüfung aktiviert lassen, den Schlüssel jedoch kontrolliert aktualisieren können, wenn Sie eine Änderung erwarten :
Entfernen Sie den alten Schlüssel und aktualisieren Sie ihn mit einem Befehl
Wiederholen Sie dies mit IP-Adressen oder anderen Hostnamen, wenn Sie diese verwenden.
Der Vorteil dieses Ansatzes besteht darin, dass der Server genau einmal neu verschlüsselt wird. Die meisten Versionen von ssh-keygen scheinen keinen Fehler zurückzugeben, wenn der zu löschende Server nicht in der bekannten Hosts-Datei vorhanden ist. Wenn dies für Sie ein Problem ist, verwenden Sie die beiden Befehle nacheinander.
Dieser Ansatz überprüft auch die Konnektivität und gibt eine nette Nachricht für die Protokolle im Befehl ssh aus (der sich anmeldet, den Hostschlüssel aktualisiert und den aktualisierten SSH-Hostschlüssel ausgibt und dann sofort beendet wird.
Wenn Ihre Version von ssh-keygen einen Exit-Code ungleich Null zurückgibt und Sie es vorziehen, diesen unabhängig von oder nach dem Herstellen einer Verbindung fehlerfrei zu verarbeiten, verwenden Sie einfach die beiden Befehle nacheinander und ignorieren Sie alle Fehler im Befehl ssh-keygen.
Wenn Sie diese Technik verwenden, müssen Sie Ihren ssh-Befehl nur während dieses einen ssh-Befehls ändern oder die Host-Überprüfung deaktivieren. Sie können sicher sein, dass zukünftige ssh-Sitzungen ohne Konflikte funktionieren oder explizit einen neuen Schlüssel akzeptieren müssen, solange der obige ssh-Befehl fehlerfrei ausgeführt wird.
quelle
Ich hatte das gleiche problem
Ich habe nur
sudo nano /home/user/.ssh/ host_allow
den Schlüssel gelöscht.Als ich zum Server zurückkehrte, fügte er einen neuen Schlüssel hinzu.
quelle
Verwenden Sie den Befehl sed, um die fehlerhafte Zeile zu entfernen
Entfernen Sie die Leitung 86 wie bei bekannten Hosts erwähnt.
Beim nächsten Zugriff mit ssh fügt das System automatisch einen neuen Schlüssel hinzu.
neuere Versionen von ssh
verwenden:
Es wird den Hostnamen Eintrag entfernen und nimmt Sicherung der alten
.known_host
alsknown_hosts.old
quelle