Frage Wie strikte RSA-Schlüssel in SSH zu entfernen und was ist das Problem hier?


Ich habe einen Linux-Server, der jedes Mal, wenn ich ihn anschließe, die Nachricht anzeigt, die den SSH-Hostschlüssel geändert hat:

$ ssh root @ host1   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@   @ WARNUNG: REMOTE HOST   IDENTIFIKATION HAT SICH GEÄNDERT! @   @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@   ES IST MÖGLICH, DASS JEMAND MACHT   ETWAS ETWAS! Jemand könnte sein   belausche dich gerade jetzt   (Mann-in-der-Mitte-Angriff)! Es ist auch   möglich, dass der RSA-Host-Schlüssel hat   gerade geändert worden. Der Fingerabdruck für   Der RSA-Schlüssel, der vom Remote-Host gesendet wird, ist   93: a2: 1b: 1c: 5f: 3e: 68: 47: bf: 79: 56: 52: f0: ec: 03: 6b.   Bitte kontaktieren Sie Ihr System   Administrator. Fügen Sie den richtigen Hostschlüssel hinzu   /home/emerson/.ssh/known_hosts zu bekommen   befreie diese Nachricht. Beleidigender Schlüssel in   /home/emerson/.ssh/known_hosts:377

RSA-Hostschlüssel für Host1 wurde geändert und   Sie haben eine strenge Überprüfung angefordert.   Überprüfung des Hostschlüssels fehlgeschlagen.

Es hält mich für ein paar Sekunden eingeloggt und dann schließt es die Verbindung.

host1: ~ / .ssh # Von Remote-Host host1 gelesen: Verbindung wurde durch Peer zurückgesetzt   Verbindung zu Host1 geschlossen.

Weiß jemand, was passiert und was ich tun könnte, um dieses Problem zu lösen?


36
2018-05-08 11:34


Ursprung


Dies betrügt frühere Frage: serverfault.com/questions/2988/... - Drew Stephens


Antworten:


Bitte lösche nicht die gesamte known_hosts-Datei, wie sie von einigen Leuten empfohlen wird. Dadurch wird der Punkt der Warnung vollständig gelöscht. Es ist eine Sicherheitsfunktion, um Sie zu warnen, dass ein Mann in der mittleren Attacke passiert sein könnte.

Ich schlage vor, Sie identifizieren, warum es denkt, dass sich etwas geändert hat, höchstwahrscheinlich änderte ein SSH-Upgrade die Verschlüsselungsschlüssel wegen einer möglichen Sicherheitslücke. Sie können diese bestimmte Zeile dann aus Ihrer known_hosts-Datei löschen:

sed -i 377d ~/.ssh/known_hosts

Diese dlöscht Zeile 377 wie in der Warnung nach dem Doppelpunkt:

/home/emerson/.ssh/known_hosts:377

Alternativ können Sie den relevanten Schlüssel entfernen, indem Sie folgendermaßen vorgehen

ssh-keygen -R 127.0.0.1 (obviously replace with the server's IP)

Bitte löschen Sie NICHT die gesamte Datei und vergewissern Sie sich, dass dies tatsächlich der Computer ist, mit dem Sie sich verbinden möchten, bevor Sie den spezifischen Schlüssel löschen.


61
2018-05-08 11:47



Nicht mehr als 350 Server wegen einer fehlenden Übereinstimmung löschen. Irgendeine Idee, warum es die Verbindung schließt? - setatakahashi
Ist es nicht gelöst, sobald Sie den relevanten known_hosts Datensatz entfernen? Wenn nicht, könnten Sie den ssh-Client im ausführlichen Modus ausführen und ihn irgendwo einfügen. - Adam Gibbins
Es schließt die Maschine, weil der Host-Schlüssel ungültig ist, genau wie es sagt. Wenn Sie die Sicherheit ernst nehmen, müssen Sie sich beim Administrator des Servers erkundigen, ob der Host-Schlüssel aus einem berechtigten Grund geändert wurde. Wenn ja, können Sie es ersetzen, wie von Adam erklärt. - Matthew Flaschen
Ich folgte Ihrem Vorschlag, aber $ sed -i "46 d" ~ / .ssh / known_hosts sed: 1: "/Users/myusr/.ssh ...": zusätzliche Zeichen am Ende von l Befehl, also entfernte ich es manuell mit Vim und es hat funktioniert. Danke! - Luis Ramirez-Monterosa
Adams Syntax ist nahezu korrekt, aber Sie brauchen ein Leerzeichen zwischen dem "377" und dem "d". In OS X befinden sich bekannte Hosts in ~ / .ssh / known_hosts; Beachten Sie das Fehlen eines "." im Dateinamen. - ktappe


Ich denke, obwohl einige der Antworten hier auf die empfohlene Vorgehensweise in der Frage des OP eingehen, beantwortet sie die Frage nicht vollständig.

Die Frage lautet: "Wie strikte RSA-Schlüssel in SSH zu entfernen und was ist das Problem hier?"

Das Problem hier ist, wie von einigen anderen empfohlen, eine Änderung im Host wahrscheinlich aufgrund der Neuinstallation des Servers (am häufigsten Szenario). Und die empfohlene Lösung ist in der Tat, den fehlerhaften Schlüssel aus der .ssh / authorized_keys-Datei mit einem Inline-sed zu entfernen.

Ich habe jedoch keine Antworten auf den spezifischen Teil der Frage gesehen "Wie man strikte RSA-Schlüsselprüfung in SSH entfernt".

Sie können die StrictHostKey-Überprüfung in Ihrer ssh-Konfigurationsdatei, die normalerweise unter gespeichert ist, entfernen ~/.ssh/config.

Ein Beispiel für einen Host-Block ist unten aufgeführt:

Host 101
  HostName yourip|hostname
  User youruserid
  IdentityFile /path/to/keyfile
  Port 22
  StrictHostKeyChecking no

Die speziell hinzugefügte Zeile ist die letzte Zeile StrictHostKeyChecking no was macht genau das. Abhängig von Ihrem spezifischen Szenario kann dies für Sie nützlich sein, z. B. das Ausführen mehrerer virtualisierter Container auf einem dedizierten Server mit nur wenigen ips, das Stoppen und Starten einer anderen Instanz auf derselben IP-Adresse.


20
2017-08-15 16:38



+1 Da dieser Beitrag den strikten Prüfabschnitt der Fehlermeldung tatsächlich adressiert. - Shibumi
+1 von mir auch für den Inhalt der Frage. Abhängig von Faktoren kann es mehr zu tun geben. Dieser Ansatz verschlechtert die Host-Überprüfung von "strikt" auf "einige" (meine Terminologie). In meiner Situation, die ssh mit der Erlaubnis verließ, mich davon abzuhalten, mich anzumelden, weil die Weise, die ich mich anmelden wollte, war, ein Kennwort einzugeben, und das wurde durch "einige" Wirtsprüfung deaktiviert. Sie müssen ssh also anweisen, / dev / null als "UserKnownHostsFile" zu verwenden. Dies setzt die Hostüberprüfung auf "none" und die oben genannten DIRE WARNINGS gelten. Gehen Sie also nicht global oder permanent vor. - cardiff space man
Das ist wirklich eine elegante Lösung. Danke für das Teilen! - Leon li


Eine andere Möglichkeit, StrictHostKeyChecking zu entfernen, wenn Sie es nur für einen einzelnen Server tun müssen:

ssh <server> -o StrictHostKeyChecking=no

9
2017-10-10 16:17



Lassen Sie sich einloggen, beheben Sie das Problem jedoch nicht dauerhaft. - Andres Canella
Wenn ich es mache, gibt es mir die Möglichkeit, den Schlüssel hinzuzufügen, der dann das Problem dauerhaft behebt - Greg Dougherty
Vielleicht haben wir ein anderes Thema? Ich verbinde mich mit einem Server, der vorher eine andere IP hatte. - Andres Canella
Wenn Sie einen Server haben, dessen Daten sich geändert haben, müssen Sie ihn aus Ihrer bekannten hosts-Datei löschen (nachdem Sie festgestellt haben, dass die Änderung korrekt ist) und seine neuen Informationen hinzufügen. Wenn Sie einen neuen Server haben, können Sie mit -o eine Verbindung zum Server herstellen und dessen Informationen hinzufügen. - Greg Dougherty


Zuallererst, ist das deine Maschine? Hast du wissentlich die Host Keys geändert? Wenn nicht, wäre ich sehr besorgt, dass etwas diese Daten verändert hat.

Zweitens, drehen Sie das ssh Debugging auf,

ssh -vvv user@host

und sehen Sie sich an, was Ihnen das sagt, versuchen Sie auch, in / var / log / secure und / var / log / messages auf dem Server nachzuschauen, mit dem Sie versuchen, eine Verbindung herzustellen, sshd liefert gute Fehlermeldungen.

Drittens, ist diese Maschine mit dem Internet verbunden? Sollten Sie Root-Logins wirklich erlauben?


5
2018-05-09 14:51



+1 für den Root-Logins-Kommentar - Fahad Sadah
Dieser Fehler tritt nur auf, wenn der Zielcomputer erneut erstellt wird. Wenn Sie eine Verbindung zu einem Ziel auf Ihrer Seite einer DMZ herstellen, ist ein MitM-Angriff sehr unwahrscheinlich. - ktappe


Sie erhalten dies, weil sich etwas geändert hat (wie neue NIC, neue IP, Änderung der Serversoftware usw.). Sicherheitsfokus hat einen schönen Artikel dazu SSH-Hostschlüsselschutz.

Entfernen Sie einfach den Schlüssel (mit SFTP oder ähnlichem) vom Server, indem Sie die $HOME/.ssh/known_hosts Datei, und akzeptieren Sie die neue bei der nächsten Verbindung.

Ihre Verbindung wird möglicherweise wegen der StrictHostKeyChecking-Einstellung gelöscht. Sehen Dieser Thread für ein ähnliches Problem.


3
2018-05-08 11:41



Nein, bitte tu das nicht. Dies macht die Sicherheit, die diese Funktion bietet, vollständig ungültig. Bitte entfernen Sie nur den spezifischen Schlüssel, der geändert wurde, nicht alle bekannten_Hosts. - Adam Gibbins
Ich empfehle nicht, die known_hosts-Datei zu entfernen, ich empfehle, sie zu bearbeiten und den Schlüssel daraus zu entfernen.
Ooop, Entschuldigung, falsch gelesen. - Adam Gibbins
Diese Nachricht kann sicherlich nicht durch eine neue IP-Adresse ausgelöst werden, geschweige denn durch eine neue NIC. Siehe Adam Gibbins korrekte Antwort. - bortzmeyer
Bevor Sie abstimmen (ich finde Leute, die sehr glücklich damit sind), machen Sie Ihre Nachforschungen. Lesen Sie diesen Artikel zum Sicherheitsfokus, securityfocus.com/infocus/1806. Ich zitiere ein wenig davon: "Warum kann sich ein Host-Schlüssel ändern? Der Rechner, zu dem Sie eine Verbindung herstellen möchten, wurde auf einen anderen DNS-Namen oder eine andere IP-Adresse verschoben, oder er wurde komplett durch einen neuen ersetzt." Wenn eine Antwort schrecklich falsch ist, bitte erlauben Sie eine Korrektur. Immerhin ist dies ein Wiki.


Da der 'Host' [allgemein definiert, könnte es alles sein, von einer Neuinstallation / Multiboot zu einem völlig anderen Computer mit einer IP-Adresse, mit der Sie zum Beispiel zuvor verbunden haben] erscheint der ssh-Client, der geändert werden soll Error.

Es ist nicht notwendig, die strenge Überprüfung auszuschalten, noch ist das Löschen von gespeicherten Schlüsseln im Großraum sinnvoll.

Es ist durchaus möglich, zwei verschiedene Schlüssel in known_hosts für einen bestimmten Hostnamen oder eine IP-Adresse anzugeben; Geben Sie zwei Alternativen, je nachdem, ob Sie denken, dass Sie den "alten" Schlüssel benötigen, der derzeit in known_hosts gespeichert ist

Löschen Sie entweder den bestimmten Schlüssel, auf den er sich bezieht, bei l377 von known_hosts für das OP, oder behalten Sie beide bei

Der einfachste Weg, beides zu behalten und das Löschen von Schlüsseln in known_hosts zu vermeiden, ist

  1. Bearbeiten Sie providered_hosts, um # zu Beginn des 'alten' Eintrags hinzuzufügen, auf den referent_hosts [@ l377] temporär verweist
  2. Verbinden Sie [ssh mit dem Host], stimmen Sie der Aufforderung zu, den neuen Schlüssel "automatisch" hinzuzufügen
  3. Bearbeiten Sie dann die bekannten_Hosts, um die # zu entfernen.

mehr Antworten bei "Fügen Sie den richtigen Hostschlüssel in known_hosts" / mehrere ssh Hostschlüssel pro Hostname hinzu?


2
2018-06-05 13:26