Warnung: Remote Host Identification Has Changed – Ursachen und Lösungen

SSH ist ein sicheres Netzwerkprotokoll, das einen verschlüsselten Tunnel zwischen Systemen aufbaut. Es ist besonders bei Entwicklern beliebt, die Remote-Zugriff auf Rechner ohne grafische Oberfläche benötigen. Obwohl SSH seit Jahrzehnten im Einsatz ist und zuverlässig funktioniert, können dabei bestimmte Fehler auftreten.

Viele dieser Fehler sind in der SSH-Community bekannt, und Lösungen dafür sind gut dokumentiert. Dazu gehören Firewall-Inkompatibilität, SSH Problem mit der Injektion öffentlicher Schlüssel, SSH DateiSchlüssel-Modus Fehler, und die Fehlermeldung "Warning: Remote Host Identification Has Changed".

Dieser Fehler tritt auf allen gängigen Betriebssystemen auf, einschließlich Windows, Linux und macOS. Die Ursache kann ein echtes Sicherheitsproblem sein, kein bloßer technischer Fehler. In diesem Artikel erklären wir, warum das passiert, was es für die Sicherheit Ihrer SSH-Verbindung bedeutet und wie Sie es auf den jeweiligen Plattformen beheben.

Das löst die Warnung aus: Remote Host Identification Has Changed (und solltest du dir Sorgen machen?)

Die Warnung "Warning: Remote Host Identification Has Changed" erscheint, wenn der SSH Public Key, der in deinem gespeichert ist known_hosts Die Datei stimmt nicht mit dem Schlüssel überein, den der Server aktuell präsentiert. Diese Abweichung aktiviert den integrierten Sicherheitsmechanismus von SSH, um dich vor potenziellen Bedrohungen zu schützen.

Legitime Gründe für Host-Key-Änderungen

Es gibt mehrere harmlose Gründe, warum sich der Host-Key eines Servers ändern könnte. Manchmal siehst du Variationen wie "RSA host key has changed", je nach dem spezifischen verwendeten Key-Typ.

Infografik zu Serveränderungen, die SSH-Host-Keys verändern: OS-Upgrades, Server-Neuaufbau, Backup-Wiederherstellung, Migration von physisch zu virtuell und SSH-Konfigurationsrücksetzungen.
Serverbezogene Änderungen:

Das Betriebssystem des Servers wurde neu installiert oder aktualisiert
Der Server wurde neu aufgesetzt oder aus einem Backup wiederhergestellt
Die SSH-Konfiguration des Servers wurde zurückgesetzt
Die physische oder virtuelle Maschine wurde ersetzt
Server-Migration auf neue Hardware

Änderungen an der Netzwerkkonfiguration:

Cloud-Anbieter vergeben IP-Adressen im Laufe der Zeit neu, oder Ihre Verbindung wird über einen Load Balancer geleitet.
DHCP hat einer anderen Maschine eine IP-Adresse zugewiesen
Die IP-Adresse eines außer Betrieb genommenen Servers wurde einem neuen System zugewiesen
DNS-Einträge wurden aktualisiert und zeigen nun auf einen anderen Server

Netzwerkdiagramm, das zeigt, wie ein DHCP-Server dynamische IP-Adressen an virtuelle Maschinen vergibt - wobei die Außerbetriebnahme und Neuzuweisung von Servern zu SSH-Host-Key-Konflikten führt.

Key-Management-Maßnahmen:

Systemadministratoren haben Host-Keys aus Sicherheitsgründen manuell neu generiert
Die SSH-Serversoftware wurde neu installiert
Sicherheitsrichtlinien haben eine Key-Rotation vorgeschrieben

Es ist wichtig zu verstehen, dass Passwortänderungen von Benutzern keinen Einfluss auf Host-Keys haben. Beides sind separate Authentifizierungsmechanismen. Host-Keys ändern sich nur, wenn der Server selbst oder seine SSH-Konfiguration geändert wird.

Wann die Warnung ernst genommen werden sollte

Viele Host-Key-Änderungen sind legitim - dennoch kann eine solche Warnung auf eine echte Sicherheitsbedrohung hinweisen. Sie sollten aufmerksam werden, wenn:

Sie keine Änderungen am Server vorgenommen haben und von keiner geplanten Wartung wissen
Sie den Grund für die Key-Änderung nicht mit dem Server-Administrator klären können
Der Server über öffentliche Netzwerke oder nicht vertrauenswürdige Verbindungen erreichbar ist
Sie sich mit Produktivsystemen oder Servern verbinden, die sensible Daten enthalten

Geteilte Ansicht: legitime SSH-Änderungen in Grün im Vergleich zu Sicherheitsbedrohungsszenarien in Rot - mit einer vermummten Figur als Symbol für Man-in-the-Middle-Angriffe.
Man-in-the-Middle-Angriffe sind zwar vergleichsweise selten, kommen aber vor. Bei solchen Angriffen positioniert sich ein Angreifer zwischen Ihrem Rechner und dem legitimen Server und fängt den gesamten Datenverkehr ab.

Menschlicher Fehler und Social Engineering für 68 % aller Sicherheitsvorfälle verantwortlich sind - ein Grund mehr, wachsam zu bleiben. Wie Sie Ihre Systeme zusätzlich schützen können, erfahren Sie hier: Schutz vor Brute-Force-Angriffen.

Aktuelle Zahlen von IBM zeigen, dass die durchschnittlichen globalen Kosten eines Datenverletzung betrug 4,44 Millionen Dollar im Jahr 2025, wobei die durchschnittliche Erkennungszeit acht Monate betrug. Dies zeigt, warum der Host-Schlüssel-Verifizierungsmechanismus in SSH existiert und warum Sie diese Warnungen niemals ohne Überprüfung ignorieren sollten.

So prüfst du, ob die Warnung unbedenklich ist

Bevor Sie das Problem beheben, überprüfen Sie zunächst Folgendes:

Flussdiagramm mit fünf Methoden zur Überprüfung legitimer SSH-Host-Key-Änderungen, darunter Teamabsprache, Kontakt zum Hosting-Anbieter, sichere Kanäle und Fingerabdruckvergleich.

Frag dein Team: Falls Sie den Serverzugang teilen, fragen Sie Kollegen, ob sie Änderungen vorgenommen haben
Server-Logs prüfen: Überprüfe Wartungsprotokolle oder Changelogs auf aktuelle Aktivitäten
Kontaktieren Sie Ihren Hosting-Anbieter: Falls Sie Cloud-Dienste nutzen, prüfen Sie, ob eine Wartung stattgefunden hat
Sicheren Kanal verwenden: Stellen Sie nach Möglichkeit eine Verbindung über ein bekanntes, sicheres Netzwerk her, um den Fingerprint zu überprüfen
Fingerabdrücke vergleichen: Manche Hosting-Anbieter zeigen aktuelle SSH-Fingerprints direkt im Control Panel an

Wenn du bestätigen kannst, dass die Schlüsseländerung legitim war, kannst du den alten Schlüssel bedenkenlos entfernen und den neuen akzeptieren.

Wer dynamische IP-Neuzuweisungen oder Host-Key-Konflikte vermeiden will, trifft mit der richtigen Infrastruktur die entscheidende Wahl.

Cloudzy bietet SSH VPS Hosting mit dedizierten statischen IPs. Sie laufen auf AMD Ryzen 9-Prozessoren mit NVMe-Speicher für sofortige Befehlsausführung. Unser Netzwerk erreicht 40 Gbps an 12 globalen Standorten. Dazu kommt kostenloser DDoS-Schutz für eine sichere Verbindung.

Behebung des Fehlers „Remote Host Identification Has Changed"

Die Lösung ist einfach: Entfernen Sie den alten Schlüsseleintrag von Ihrem System. Das behebt den Konflikt und ermöglicht es Ihnen, beim nächsten Verbindungsaufbau den neuen Schlüssel zu speichern. Weitere Informationen finden Sie in unserem Leitfaden zu SSH-Clients für weitere Tools.

Das Ganze lässt sich mit einem einzigen Befehl oder durch manuelles Bearbeiten der Datei erledigen.

Methode 1: Die Kommandozeile (am schnellsten)

Diese Methode funktioniert für macOS, Linux und Windows 10+ (mit OpenSSH). Sie ist der schnellste Weg, den Fehler zu beheben. Weitere Informationen finden Sie in der ssh-keygen Handbuchseite.

Öffnen Sie Ihr Terminal.
Führen Sie diesen Befehl aus (ersetzen Sie hostname mit der IP-Adresse oder Domain Ihres Servers):

ssh-keygen -R hostname

This command automatically finds the old key in your known_hosts file and deletes it.  Method 2: Manual File Editing (macOS)

Wenn Sie lieber einen grafischen Editor verwenden, können Sie den Schlüssel manuell löschen. Die Fehlermeldung gibt in der Regel genau die Zeilennummer an, die entfernt werden muss.

Öffnen Sie Ihr Terminal und bearbeiten Sie die Datei mit Nano:

nano ~/.ssh/known_hosts

Suchen Sie die Zeile aus der Fehlermeldung. Löschen Sie sie, und drücken Sie dann Ctrl + X und Y zum Speichern.

macOS Terminal-Fenster mit nano-Editor, der die Datei known_hosts anzeigt, markierte Zeile zum Löschen mit nummerierten Schritten und Speicheranweisungen.

Lösung für Windows

Windows-Nutzer verwenden in der Regel entweder den integrierten OpenSSH-Client oder PuTTY.

Option 1: Windows OpenSSH (Windows 10/11)

Unter Windows 10 und 11 ist OpenSSH ein optionales Feature. Sie können es über Einstellungen > Apps > Optionale Features hinzufügen. Server 2025 enthält den Client, er muss jedoch zuerst aktiviert werden.

Wenn Sie PowerShell oder die Eingabeaufforderung verwenden, funktioniert der ssh-keygen Befehl aus Methode 1 auch hier.

So bearbeiten Sie die Datei manuell:

Drücken Sie Windows-Taste + R.
Typ %USERPROFILE%\.ssh und drücke Enter.
Öffne die known_hosts Datei mit Notepad.
Löschen Sie die fehlerverursachende Zeile und speichern Sie die Datei.

Hinweise zur korrekten Schlüsselverwaltung finden Sie in unserem Leitfaden zum Generieren von SSH-Schlüsseln unter Windows.

Option 2: PuTTY verwenden

PuTTY speichert Schlüssel in der Windows-Registrierung statt in einer Datei.

Öffnen Sie den Registrierungseditor (drücken Sie Windows-Taste + R, geben Sie regeditund betätigen Enter).
Navigiere zu: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
Suchen Sie den Eintrag, der dem Hostnamen oder der IP-Adresse Ihres Servers entspricht.
Klicken Sie mit der rechten Maustaste darauf und wählen Sie Löschen.

Windows PowerShell-Befehl zum Entfernen des SSH-Host-Keys, mit dem Datei-Explorer und der aktualisierten known_hosts-Datei sowie dem PuTTY-Registrierungseditor mit dem Bestätigungsdialog zum Löschen des Host-Keys.

Lösung für Linux

Die ssh-keygen Befehl, den wir behandelt haben Methode 1 ist die Standardmethode zur Behebung dieses Problems unter Linux. Sie ist schnell und nativ unterstützt.

Manuelle Bearbeitung

Wer lieber den Dateiinhalt direkt sieht, kann sie mit einem Texteditor wie Nano bearbeiten.

Öffnen Sie Ihr Terminal.
Typ nano ~/.ssh/known_hosts und drücke Enter.
Suche die Zeilennummer, die in der Fehlermeldung angegeben ist.
Lösche die Zeile und drücke dann Ctrl + X und Y zum Speichern.

Du kannst auch Vim (vim ~/.ssh/known_hosts) verwenden, wenn du damit vertraut bist.

Linux-Terminal mit ssh-keygen-Befehlen zum Entfernen von SSH-Host-Keys per Hostname und IP-Adresse, mit Erfolgsbestätigung und Beispielen der known_hosts-Datei.
Hinweis zum Deaktivieren der Prüfungen

Du kannst SSH zwingen, ohne Verifizierung zu verbinden, aber das ist riskant. Dabei wird der Schutz gegen Man-in-the-Middle-Angriffe umgangen.

Verwende diesen Ansatz nur für lokale Tests in vertrauenswürdigen Netzwerken. Für macOS und Linux gib Folgendes ein:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected]

Unter Windows funktioniert der Unix-Pfad nicht. Du musst NUL verwenden, damit die Umgehung funktioniert:

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=NUL [email protected]

Diese Overrides nicht auf öffentlichen Verbindungen oder produktiven Servern ausführen.

Das Beheben von Key-Konflikten gehört zur regelmäßigen Wartung, aber du kannst noch mehr tun, um deine Verbindung abzusichern. Bots greifen häufig den Standardport 22 mit Brute-Force-Angriffen an. Den Großteil dieses Hintergrundrauschens lässt sich vermeiden, indem du SSH-Ports unter Linux änderst auf einen weniger vorhersehbaren Wert.

Diagramm eines Man-in-the-Middle-Angriffs auf SSH: Angreifer unterbricht die Client-Server-Verbindung, Angreifer-Key vs. Server-Key, Datendiebstahl und finanzieller Schaden hervorgehoben.

Diese Methode niemals für Produktivserver oder über nicht vertrauenswürdige Netzwerke verwenden.

So vermeidest du die Meldung "Remote Host Identification Has Changed" künftig

Legitime Host-Key-Änderungen lassen sich nicht immer verhindern, aber du kannst Unterbrechungen minimieren und bessere Sicherheitspraktiken einhalten.

Kurzübersicht

Deine Rolle	Wichtigste Strategien
Systemadministratoren	Keys sichern, Änderungen dokumentieren, Zertifikate verwenden und Keys regelmäßig rotieren
Normale Benutzer	Inventar pflegen, über sichere Kanäle verifizieren und Logs überwachen
Cloud-Umgebung Benutzer	Verwenden Sie DNS-Namen, Provider-Tools und Infrastructure as Code

Infografik zu Best Practices für das SSH-Key-Management: SSH-Zertifikate verwenden, DNS-Namen einsetzen, Infrastructure as Code nutzen, Host-Keys sichern, Änderungen dokumentieren und Bastion-Hosts in Betracht ziehen.

Für Systemadministratoren

Host-Keys sichern: Keys sichern aus /etc/ssh/ vor der Neuinstallation des Betriebssystems. Anschließend wiederherstellen, um Warnungen für Ihre Nutzer zu vermeiden.

Geplante Änderungen dokumentieren: Informieren Sie Nutzer vor dem Wechsel von Keys und teilen Sie die neuen Fingerprints über einen sicheren Kanal. So können sie die Verbindung verifizieren.

SSH-Zertifikate verwenden: Große Teams sollten eine zentrale Zertifizierungsstelle einsetzen. Diese signiert Host-Keys und macht manuelle Überprüfungen überflüssig.

Key-Rotation einführen: Planen Sie Ihre Host-Key-Wechsel im Voraus. Vorhersehbare Updates sind für Ihr Team einfacher zu handhaben als unangekündigte.

Für reguläre Nutzer

Bestand verwalten: Führen Sie eine persönliche Aufzeichnung der Server-Fingerprints oder nutzen Sie die sichere Dokumentation Ihres Teams.

Out-of-Band verifizieren: Gleichen Sie Keys gegen eine vertrauenswürdige Quelle ab, etwa die Cloud-Konsole, und nicht über informelle Nachrichten.

Protokolle überwachen: Überprüfen Sie Ihre lokalen SSH-Logs regelmäßig auf ungewöhnliche Verbindungsmuster oder wiederkehrende Fehler.

Konfigurationsverwaltung nutzen: Verwenden Sie SSH-Konfigurationsdateien, um dynamische Entwicklungsumgebungen zu verwalten, ohne die Sicherheitseinstellungen zu senken.

Für dynamische Cloud-Umgebungen

DNS-Namen verwenden: Verbinden Sie sich über Hostnamen statt über IP-Adressen. Das sorgt für Konsistenz, wenn sich die zugrunde liegende Adresse ändert.

Cloud-Tools nutzen: Rufen Sie aktuelle Fingerprints über die Provider-Konsole ab. Überprüfen Sie Keys anhand dieser Tools, bevor Sie Änderungen akzeptieren.

Infrastruktur als Code: Automatisieren Sie die Key-Verifizierung mit Tools wie Terraform. Für komplexere Setups können Sie außerdem SSH SOCKS5-Proxys verwenden.

Bastion-Hosts: Richte Jump-Server mit stabilen Schlüsseln ein. Sie dienen als sichere Einstiegspunkte in deine dynamische Infrastruktur.

Fazit

Die Meldung „Warning: Remote Host Identification Has Changed" ist ein wichtiges Sicherheitsmerkmal von SSH und kein Fehler, den man ignorieren sollte. Obwohl diese Warnung häufig aus legitimen Gründen wie Serverwartung oder Konfigurationsänderungen erscheint, spielt sie eine entscheidende Rolle beim Schutz vor Man-in-the-Middle-Angriffen und unbefugtem Zugriff.

Wenn Sie diese Warnung erhalten, überprüfen Sie zuerst die Ursache. In den meisten Fällen ist die Lösung einfach: Entfernen Sie den alten Host-Schlüssel mit einer der beschriebenen Methoden für Ihr Betriebssystem und akzeptieren Sie beim nächsten Verbindungsaufbau den neuen Schlüssel.

Wenn Sie verstehen, wie SSH Host-Keys funktionieren, und bewährte Methoden einhalten, lassen sich Sicherheit und Komfort bei der Fernzugriffsverwaltung gut vereinen. Mehr zum sicheren Dateitransfer finden Sie unter Dateien über SSH kopieren.

Häufig gestellte Fragen

Sollte ich die Warnung "Remote Host Identification Has Changed" ernst nehmen?

Ja, das sollte man ernst nehmen. Es bedeutet, dass sich die Identität des Servers geändert hat – das kann auf einen Man-in-the-Middle-Angriff hindeuten oder einfach auf routinemäßige Wartungsarbeiten zurückzuführen sein. Klären Sie die Änderung immer mit Ihrem Administrator oder Anbieter ab, bevor Sie den neuen Schlüssel akzeptieren.

Was löst die Warnung aus: Die Identifikation des Remote-Hosts hat sich geändert?

Diese Warnung erscheint, wenn der aktuelle Fingerabdruck des Servers nicht mit dem Eintrag in deiner known_hosts-Datei übereinstimmt. Häufige Ursachen sind Neuinstallationen des Betriebssystems, neu zugewiesene IP-Adressen oder SSH-Konfigurationszurücksetzungen. In seltenen Fällen kann dies auf einen aktiven Man-in-the-Middle-Angriff hinweisen.

Kann dieser Fehler auf verschiedenen Betriebssystemen auftreten?

Ja, diese Warnung betrifft alle Betriebssysteme, die SSH verwenden – darunter Windows, macOS und Linux. Sie wird durch die Sicherheitsverifizierung des SSH-Protokolls ausgelöst. Die Behebung unterscheidet sich je nach Plattform, der zugrunde liegende Sicherheitsauslöser ist jedoch auf allen Systemen identisch.

Woran erkenne ich, ob eine Host-Key-Änderung legitim ist oder auf einen Angriff hindeutet?

Um die Echtheit zu bestätigen, prüfe zunächst, ob kürzlich Wartungsarbeiten, OS-Updates oder IP-Änderungen stattgefunden haben. Vergleiche den neuen Fingerprint mit einer vertrauenswürdigen Quelle - etwa der Konsole deines Cloud-Anbieters oder einer Bestätigung deines Systemadministrators - bevor du dich verbindest.

Macht das Deaktivieren der Host-Key-Überprüfung SSH bequemer?

Es erhöht zwar den Komfort, aber auf Kosten der Sicherheit. Wer die Zertifikatsprüfung deaktiviert, öffnet Verbindungen für Man-in-the-Middle-Angriffe. Diese Einstellung gehört ausschließlich in isolierte Testumgebungen - niemals auf Produktionsserver oder öffentliche Netzwerke, in denen sensible Daten übertragen werden.

Wie oft sollten SSH Host-Keys gewechselt werden?

Host-Keys müssen in der Regel nicht regelmäßig ausgetauscht werden. Ein Wechsel ist typischerweise nur nach einem Server-Rebuild, einer Neuinstallation des Betriebssystems oder einem Sicherheitsvorfall sinnvoll. Häufige Änderungen stören den Betrieb der Nutzer – setze daher auf Stabilität und kommuniziere notwendige Updates klar und rechtzeitig.

Warnung: Remote Host Identification Has Changed – Ursache und Lösung