☰

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

tag-icon • tag-icon ubuntu ssh ssh-keys hostkey
Der SSH-Hostschlüssel scheint sich unerwartet zu ändern

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

HostKey /etc/ssh/ssh_host_ecdsa_key

Ich bemerkte, dass ich ab diesem Zeitpunkt viele ähnliche, aber unterschiedliche Fehlermeldungen bekam, wenn ich versuchte, mich mit der Box zu verbinden, wie zum Beispiel: „Der RSA-Hostschlüssel für%hostname%hat sich geändert und der Schlüssel für die entsprechende IP-Adresse%IP Adresse% bleibt unverändert."

Ich nahm an, dass dies daran lag, dass mein Computer zuvor standardmäßig den ECDSA-Schlüssel verwendete und dieser nun nicht mehr verfügbar war. Also fügte ich diese Zeile wieder hinzu sshd_configund startete SSH neu.

Das Problem wurde dadurch nicht vollständig gelöst und ich habe seitdem ständig Probleme. Ich kann mich mehrmals problemlos mit dem Server verbinden, vielleicht sogar mehrere Tage hintereinander. Dann bekomme ich plötzlich Fehlermeldungen, 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, wenn ich eine Weile damit herumspiele und mich von einem anderen Standort aus verbinde, plötzlich wieder in der Lage bin, mich mit meinem öffentlichen Schlüssel zu verbinden und nicht mehr die Fehlermeldung über einen möglichen Man-in-the-Middle-Angriff erhalte.

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, das Problem wäre dann vielleicht behoben, aber jetzt ist das Problem wieder da.

Seit ich die Hostschlüssel das /etc/ssh/letzte Mal neu generiert habe, wurden sie nicht geändert. Was könnte also die Ursache dafür sein, dass ich häufig keine Verbindung herstellen kann, mein öffentlicher Schlüssel nicht funktioniert, ich dann aber schließlich den neuen Schlüssel akzeptiere und alles für eine Weile wieder einwandfrei funktioniert?

Wenn etwas nicht funktioniert (wenn ich die Fehlermeldung bekomme, dass sich der Hostschlüssel geändert hat und der Server dann meinen öffentlichen Schlüssel nicht mehr akzeptiert), wird nichts in die Server-ID geschrieben /var/log/auth.log. Das lässt mich vermuten, dass es manchmal vielleicht irgendwie eine andere Maschine trifft, aber ich weiß auch nicht, wie das möglich ist, da der DNS-Eintrag korrekt ist und immer dieselbe IP-Adresse zurückgibt.

Antwort1

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

  1. Sie haben die Hostschlüssel selbst geändert und sie auf Ihren Client-Rechnern nicht gelöscht oder aktualisiert.
    Dies ist die häufigste Situation. Berechnen Sie die Prüfsumme der Schlüsseldateien und stellen Sie ABSOLUT SICHER, dass sie sich nicht geändert haben.

  2. Sie haben Ihre SSH-Konfiguration geändert, um einen anderen Schlüsseltyp als zuvor anzuzeigen (oder anzufordern).
    Beispielsweise wollten Sie vorher 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 machen Sie die Änderung rückgängig, wenn dies nicht das ist, was Sie wollten).
    (Es klingt, als wären Sie in Situation Nr. 2 – machen Sie Ihre Änderungen rückgängig, starten Sie sshd neu und überprüfen Sie, ob alles wie erwartet funktioniert. Wenn Sie die neuen Schlüssel nirgends akzeptiert haben, sollte der Fehler durch Rückgängigmachen der Änderung behoben werden.)

  3. JEMAND TUT ETWAS BÖSES
    Der Man-in-the-Middle-Angriff, vor dem SSH Sie warnt, hat sein hässliches Gesicht gezeigt. Jemand versucht aktiv, Ihre Kommunikation abzufangen, um Ihren privaten Schlüssel zu stehlen oder etwas anderes zu tun, was Sie mit ziemlicher Sicherheit nicht wollen.

Wenn Sie 1 ausgeschlossen haben und sicher sind, 2 nicht getan zu haben, müssen Sie 3 annehmen, bis Sie das Gegenteil beweisen können. Das bedeutetNicht anmelden. – Die ganze SSH-Sicherheit der Welt hilft nichts, wenn Benutzer das große 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 bekannten guten Terminal), während Sie versuchen, sich anzumelden, usw. -- es gibt so viele Möglichkeiten, hier einen Angriff auszuführen, dass ich nicht alle möglichen Gegenmaßnahmen und Erkennungsstrategien aufzählen kann, aber die Leute beiIT Sicherheithätte sicher noch ein paar Ideen.

Antwort2

wenn möglich/zum Testen/Debuggen:

  • verwenden Sie IPs statt Hostnamen (nur um sicherzugehen)
  • Gibt es im Netz mehrere Maschinen mit derselben IP (per DHCP zugewiesene IP, die von einem anderen Host mit fester IP verwendet wurde)?
  • Wenn Maschinen DHCP verwenden, können sich ihre IPs zufällig ändern (Reihenfolge beim Systemstart 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 IPs/Hostnamen

Zum Beispiel:

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

verwandte Informationen