WardtermSSH-Client
DE
Herunterladen

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! Was tun?

Der Server hat einen anderen Schlüssel vorgelegt als den, der in Ihrer known_hosts gespeichert ist. Das ist nach einem Neuaufbau normal, und genau so sieht auch ein Angriff aus. Besorgen Sie sich den echten Fingerprint auf anderem Weg, etwa über die Konsole des Anbieters, vergleichen Sie ihn und führen Sie erst dann ssh-keygen -R server aus und verbinden Sie sich erneut. Nutzen Sie niemals StrictHostKeyChecking=no, um darüber hinwegzukommen.

known_hosts lieber nicht von Hand bearbeiten? Wardterm führt den Fingerprint jedes Servers in einer Liste, die Sie prüfen und bereinigen können. Zeigen

Aktualisiert am . Reproduziert mit OpenSSH 10.3 unter macOS, indem die Host-Schlüssel eines Wegwerf-Containers mit Debian 13 und OpenSSH 10.0 neu erzeugt wurden.

Die Meldung

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 ED25519 key sent by the remote host is
SHA256:iU7+QOFWSHJeCFBdzU31dTOoJRNhncp+Wzw3UJMzasU.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/user/.ssh/known_hosts:1
Host key for server has changed and you have requested strict checking.
Host key verification failed.

Ein Server beweist seine Identität mit seinem Host-Schlüssel. Ihr Computer hat diesen Schlüssel bei der ersten Verbindung gespeichert. Jetzt hat er einen anderen erhalten, und ssh hat angehalten, bevor etwas gesendet wurde. Die zwei Angaben, die Sie brauchen, sind der neue Fingerprint (die Zeile mit SHA256:) und die Stelle des alten Eintrags (known_hosts:1 ist Zeile 1). Unter Debian und Ubuntu schlägt die Meldung auch einen ssh-keygen -R-Befehl vor: Führen Sie ihn erst nach der Prüfung unten aus.

Harmlose Ursache oder Angriff?

Häufige harmlose Ursachen:

  • Der Server wurde neu aufgebaut, neu installiert oder wiederhergestellt, was oft neue Host-Schlüssel erzeugt.
  • Die Adresse gehört jetzt einem anderen Rechner: eine neue VM auf einer wiederverwendeten Cloud-IP oder eine verschobene Elastic IP.
  • Ein Load Balancer oder ein Failover-Paar schickt Sie zu einem Rechner mit anderen Schlüsseln.
  • Ein weitergeleiteter Port wie localhost:2222 führt jetzt woandershin.
  • Ein Administrator oder ein Dienst hat die Schlüssel getauscht, wie GitHub im März 2023 seinen RSA-Host-Schlüssel.
  • Der Server bietet den gespeicherten Schlüsseltyp nicht mehr an. In unserem Test löste ein auf RSA beschränkter Server diese Warnung bei einem Client aus, der seinen ED25519-Schlüssel gespeichert hatte.

Seien Sie misstrauisch, wenn niemand die Änderung erklären kann, wenn sie nur in einem Netz auftritt, etwa im öffentlichen WLAN, oder wenn es ein Server ist, den niemand angefasst hat. Geben Sie, bis Sie es wissen, kein Passwort ein und führen Sie nichts auf ihm aus. Ein Versuch aus einem anderen Netz hilft: Unterscheiden sich die Fingerprints zwischen Netzen, stört etwas in einem von ihnen.

Den neuen Fingerprint außerhalb des Kanals prüfen

Außerhalb des Kanals heißt über einen Weg, den ein Angreifer auf dieser Verbindung nicht kontrollieren kann: die Web-Konsole des Anbieters, eine serielle Konsole, physischer Zugang oder ein Kollege mit verifiziertem Zugang. Führen Sie auf dem Server aus:

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
256 SHA256:iU7+QOFWSHJeCFBdzU31dTOoJRNhncp+Wzw3UJMzasU root@server (ED25519)

Nehmen Sie die Datei für den in der Warnung genannten Schlüsseltyp: ssh_host_rsa_key.pub oder ssh_host_ecdsa_key.pub für die anderen. Der Wert muss genau zur Warnung passen. Manche Cloud-Images geben die Fingerprints beim ersten Start auch ins Konsolen-Log aus.

Der folgende Befehl zeigt nur, was der Server auf Ihrem aktuellen Netzwerkpfad sendet. Er ist praktisch, um einen Wert auszulesen, beweist aber für sich nichts, denn ein Angreifer würde ihm denselben gefälschten Schlüssel schicken:

ssh-keyscan -t ed25519 server | ssh-keygen -lf -

Den alten Schlüssel entfernen

ssh-keygen -R server
# Host server found: line 1
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old

Das funktioniert auch bei gehashten Namen, und Sie müssen die Datei nicht von Hand bearbeiten. Verwenden Sie denselben Namen, mit dem Sie sich verbinden. Manche Setups brauchen mehr als einen Aufruf:

ssh-keygen -R 203.0.113.10
ssh-keygen -R '[server]:2222'

Die zweite Form ist für einen Server auf einem anderen Port als 22.

Erneut verbinden und vergleichen

ssh user@server
The authenticity of host 'server (203.0.113.10)' can't be established.
ED25519 key fingerprint is: SHA256:iU7+QOFWSHJeCFBdzU31dTOoJRNhncp+Wzw3UJMzasU
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Vergleichen Sie, oder besser, fügen Sie an dieser Abfrage den Fingerprint ein, den Sie aus der Konsole haben. ssh vergleicht dann für Sie und fragt erneut, wenn sie nicht übereinstimmen.

Warum nicht StrictHostKeyChecking=no

Das ist der Rat, den Sie am häufigsten finden, und er beseitigt den Schutz vollständig. Wir haben es gegen einen geänderten Schlüssel probiert. Es gibt die Warnung weiterhin aus und macht dann weiter:

Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
Agent forwarding is disabled to avoid man-in-the-middle attacks.

Die Schlüssel-Anmeldung ging trotzdem durch, Sie arbeiten also auf einem Server, den Sie nicht verifiziert haben, und alles, was Sie dort tippen oder kopieren, kann einen Angreifer erreichen. Auch UserKnownHostsFile=/dev/null richtet ähnlichen Schaden an: Nichts wird je gemerkt, also kann nie etwas geprüft werden.

Für Skripte, die auf neue Hosts treffen, nutzen Sie StrictHostKeyChecking=accept-new. Es speichert Schlüssel neuer Hosts und weist einen geänderten Schlüssel weiterhin ab, wie wir bestätigt haben. Siehe known_hosts erklärt.

Für Skripte und CI, die mit einer einzigen Zeile abbrechen, siehe Host key verification failed in Skripten und CI.

Die Warnung bei geplanten Änderungen vermeiden

  • Wenn Sie einen Server neu aufbauen, stellen Sie seine alten Host-Schlüssel aus Ihrem sicheren Backup wieder her, sofern Ihre Richtlinie es erlaubt.
  • Für eine Gruppe von Rechnern hinter einem Namen nutzen Sie Host-Zertifikate, damit Clients einer CA vertrauen statt jedem einzelnen Schlüssel.
  • Zum Rotieren von Schlüsseln fügen Sie zuerst den neuen hinzu, lassen Clients ihn per UpdateHostKeys lernen und entfernen erst dann den alten.

Fragen

Reicht es, ssh-keygen -R auszuführen?

Erst nachdem Sie den neuen Fingerprint über einen anderen Weg bestätigt haben. Der Befehl entfernt die Warnung, nicht ihre Ursache, und kann so allein einen Angriff verdecken.

Warum erscheint die Warnung nach der Neuinstallation des Servers?

Eine Neuinstallation erzeugt meist neue Host-Schlüssel, der Schlüssel passt also nicht mehr zum Eintrag in known_hosts. Vergleichen Sie den neuen Fingerprint über die Konsole und entfernen Sie dann den alten Eintrag.

Kommt man mit StrictHostKeyChecking=accept-new an der Warnung vorbei?

Nein. accept-new speichert nur Schlüssel von Hosts, die es nie gesehen hat. Ein geänderter Schlüssel wird weiter abgelehnt.

Quellen

Mehr zu Fehlermeldungen

Alle Anleitungen