Der SSH-Hostschlüssel scheint sich unerwartet zu ändern

Ich habe /etc/ssh/sshd_configmit Puppet eine neue Version auf einem Ubuntu 12.04-Testserver eingeführt. Die Konfiguration war genau die gleiche wie die vorherige Konfiguration, außer dass die folgende Zeile entfernt wurde:

HostKey /etc/ssh/ssh_host_ecdsa_key

Ich habe festgestellt, dass beim Versuch, eine Verbindung zur Box herzustellen , viele ähnliche, aber unterschiedliche Fehler aufgetreten sind, z. B .: "Der RSA- Hostschlüssel für % hostname% hat sich geändert, und der Schlüssel für die entsprechende IP-Adresse % ipaddress% ist unverändert. ""

Ich nahm an, dass dies daran lag, dass mein Computer zuvor standardmäßig den ECDSA-Schlüssel verwendete und dieser jetzt nicht verfügbar war. Also habe ich diese Zeile wieder zu sshd_configSSH hinzugefügt und SSH neu gestartet.

Das Problem wurde dadurch nicht vollständig gelöst, und seitdem habe ich ständig Probleme. Ich kann mich mehrmals problemlos mit dem Server verbinden, vielleicht sogar mehrere Tage hintereinander. Dann erhalte ich plötzlich Fehler, dass sich der Hostschlüssel geändert hat und der Server meinen öffentlichen Schlüssel nicht mehr zur Authentifizierung akzeptiert.

Es scheint immer so, dass ich, sobald ich eine Weile damit herumgespielt und von einem anderen Ort aus eine Verbindung hergestellt habe, plötzlich wieder eine Verbindung mit meinem öffentlichen Schlüssel herstellen kann und nicht mehr den Fehler über einen möglichen Mann in der Mitte erhalte Attacke.

Ich habe vor einigen Tagen versucht, alle 3 Hostschlüssel neu zu generieren (habe sie entfernt und ausgeführt, dpkg-reconfigure openssh-serverwodurch sie neu generiert wurden). Wie erwartet musste ich die alten Schlüssel entfernen und die neuen akzeptieren, bevor ich eine Verbindung herstellen konnte. Ich dachte, vielleicht wurde es damals behoben, aber das Problem ist jetzt zurück.

/etc/ssh/Seit ich sie zuletzt neu generiert habe, hat sich an keinem der Hostschlüssel etwas geändert. Was kann also dazu führen, dass ich häufig keine Verbindung herstellen kann, mein öffentlicher Schlüssel nicht funktioniert, dann den neuen Schlüssel akzeptiert und die Dinge wieder einwandfrei funktionieren für eine Weile?

Wenn die Dinge nicht funktionieren (wenn der Fehler beim Ändern des Hostschlüssels auftritt und der Server meinen öffentlichen Schlüssel nicht mehr akzeptiert), wird nichts auf den Server geschrieben /var/log/auth.log. Dies lässt mich denken, dass es manchmal irgendwie auf einen anderen Computer trifft, aber ich weiß auch nicht, wie das möglich ist, da der DNS-Eintrag korrekt ist und immer dieselbe IP-Adresse zurückgibt.

— Ben
quelle

Siehe auch

— Zoredache

Es hängt damit zusammen, aber meine Frage ist eher, warum dieses Problem immer wieder auftritt, wenn sich die Schlüssel des Servers nicht ändern, als was zu tun ist, wenn ich den Fehler erhalte.

— Ben

Antworten:

Es gibt drei häufige Gründe, warum Sie diese Nachricht erhalten würden.
In grober Reihenfolge der Wahrscheinlichkeit sind sie:

Sie haben die Hostschlüssel selbst geändert und sie auf Ihren Clientcomputern nicht gelöscht oder aktualisiert.
Dies ist die häufigste Situation. Prüfen Sie die Schlüsseldateien und seien Sie absolut sicher, dass sie sich nicht geändert haben.
Sie haben Ihre SSH-Konfiguration geändert, um einen anderen Schlüsseltyp als zuvor anzuzeigen (oder anzufordern).
zB wollten Sie früher RSA- oder DSA-Schlüssel, jetzt verwenden Sie ECDSA - das ist eine "Schlüsseländerung".
Wenn dies der Fall ist, überprüfen und akzeptieren Sie die neuen Schlüssel (oder wenn dies nicht Ihren Wünschen entspricht, machen Sie die Änderung rückgängig).
(Es hört sich so an, als wären Sie in Situation 2 - Machen Sie Ihre Änderungen rückgängig, starten Sie sshd neu und stellen Sie sicher, dass die Dinge wie erwartet funktionieren. Wenn Sie die neuen Schlüssel nirgendwo akzeptiert haben, sollte der Fehler behoben werden, wenn Sie die Änderung rückgängig machen.)
JEMAND TUT ETWAS SCHLECHTES
Der Man-in-the-Middle-Angriff, vor dem SSH Sie warnt, hat seinen hässlichen Kopf aufgerichtet. Jemand versucht aktiv, Ihre Kommunikation abzufangen, um Ihren privaten Schlüssel zu stehlen oder etwas anderes zu tun, das Sie mit ziemlicher Sicherheit nicht möchten.

Wenn Sie 1 eliminiert haben und sicher sind, dass Sie 2 nicht gemacht haben, müssen Sie 3 annehmen, bis Sie das Gegenteil beweisen können. Das heißt, nicht anmelden . - Die gesamte SSH-Sicherheit der Welt hilft nicht, wenn Benutzer das große riesige Warnbanner ignorieren und ihre Schlüssel an Angreifer übergeben.

Untersuchen Sie den Kanal zwischen Ihnen und Ihrem Server, überprüfen Sie die Verbindungsprotokolle des Servers (von einem bekanntermaßen guten Terminal), während Sie versuchen, sich anzumelden usw. - hier gibt es so viele Möglichkeiten, einen Angriff auszuführen, dass ich nicht alle auflisten kann mögliche Gegenmaßnahmen und Erkennungsstrategien, aber die Leute von IT Security hätten sicherlich einige Ideen.

— voretaq7
quelle

Danke für die schnelle Antwort. Ich glaube, dass ich # 1 und # 2 eliminieren kann, da ich jedes Mal, wenn dies passiert, den alten Schlüssel entferne und den neuen Schlüssel während der Fehlerbehebung zu meiner Datei "unknown_hosts" hinzufüge, wodurch ich mich manchmal mit der Pubkey-Authentifizierung anmelden kann und manchmal (normalerweise von meinem Windows-Computer) Es gibt mir immer noch Probleme. Trotzdem bekomme ich es irgendwann von überall zum Laufen, und dann vergeht eine gewisse Zeit und ich bekomme eine weitere Warnung wie diese. Es lässt mich denken, dass es # 3 sein könnte, aber bis jetzt sehe ich keine Beweise dafür

— Ben

Und es scheint auch seltsam, dass dies damit zusammenfiel, dass ich die sshd-Konfiguration änderte (aber dann wieder änderte - selbst wenn die Datei mit dem Original abweicht, werden keine Änderungen angezeigt) und mir erst danach Probleme bereitete. Ich dachte, ich hätte vielleicht etwas an der Maschine vermasselt, aber ich habe diese Konfiguration erneut abgebildet und erneut angewendet (mit Puppe, aber das sollte keine Bedeutung haben, da Puppe keine Änderungen vornimmt, wenn dieses Problem auftritt) und Ich habe jedes Mal das gleiche Problem in scheinbar zufälligen Abständen.

— Ben

Eine weitere interessante Information (möglicherweise) ist, dass sich der Fehler manchmal auf den RSA-Hostschlüssel des Servers und manchmal auf den ECDSA-Hostschlüssel bezieht. Ist es normal, dass beide Schlüsseltypen von derselben Maschine überprüft werden?

— Ben

@ Ben Es gibt andere mögliche Ursachen, die ich nicht aufgelistet habe - aber dies sind die drei, die ich tatsächlich in der realen Welt gesehen habe. Wenn Sie sich über den Konfigurationsstatus sicher sind, versuchen Sie es mit ssh-keyscaneinigen der betroffenen Clientcomputer und überprüfen Sie die Serverprotokolle. Beachten Sie auch, dass wenn Sie etwas Ungewöhnliches tun, wie das Teilen Ihrer known_hostsDatei zwischen verschiedenen Versionen des SSH-Clients, dies eine mögliche Ursache für diese Seltsamkeit sein könnte (ich habe so etwas noch nie gemacht, daher kann ich nicht sicher sagen ... )

— voretaq7

Sie haben mir geholfen, das einzugrenzen. Ich habe einige zusätzliche Überprüfungen durchgeführt und festgestellt, dass die Nameserver bei Rackspace zwei verschiedene Datensätze für denselben Hostnamen zurückgeben. Ich weiß nicht, woher eine kam, aber es schien, dass entweder die eine oder die andere IP zuerst in der Liste zurückgegeben wird (scheinbar zufällig). Ich habe schließlich den streunenden DNS-Eintrag gefunden und beseitigt und habe dieses Problem seitdem nicht mehr erhalten.

— Ben

wenn möglich / zum Testen / Debuggen:

Verwenden Sie IPs anstelle von Hostnamen (nur um sicherzugehen)
Gibt es mehrere Computer mit derselben IP (DHCP hat IP angegeben, die von einem anderen Host mit fester IP verwendet wurde) im Netz?
Wenn Computer DHCP verwenden, können sich ihre IP-Adressen zu zufälligen Zeiten ändern (Reihenfolge des Startvorgangs usw.). Vielleicht versuchen Sie jetzt, eine Verbindung zu einem anderen Host herzustellen. Aktivieren Sie die Kennwortauthentifizierung und sehen Sie, wo Sie landen.
Suchen Sie auf dem Client cat /home/username/.ssh/known_hosts nach Zeilen mit doppelten Schlüsseln, aber unterschiedlichen IP- / Hostnamen

zum Beispiel:

192.168.56.3 ecdsa-sha2-nistp256 AAAAE2...fPfFAyoGSVAvs=
192.168.56.4 ecdsa-sha2-nistp256 AAAAE2...fPfFAyoGSVAvs=

— abknutschen
quelle