Warnung: Die Remote-Host-Identifizierung hat sich geändert und wie man sie behebt

SSH ist ein sicheres Netzwerkprotokoll, das einen verschlüsselten Tunnel zwischen Systemen erstellt. Es bleibt bei Entwicklern beliebt, die Fernzugriff auf Computer benötigen, ohne eine grafische Benutzeroberfläche zu benötigen. Obwohl es SSH schon seit Jahrzehnten gibt und es unzähligen Benutzern zuverlässig zur Verfügung steht, kann es immer noch von bestimmten Fehlern betroffen sein.

Viele dieser Fehler sind in der SSH-Community bekannt geworden und ihre Problemumgehungen sind ausführlich dokumentiert. Dazu gehören Firewall-Inkompatibilität, Probleme mit der Injektion öffentlicher SSH-Schlüssel, Probleme mit dem SSH-Dateischlüsselmodusund der Fehler „Warnung: Remote-Host-Identifikation hat sich geändert“.

Dieser Fehler tritt auf allen wichtigen Betriebssystemen auf, einschließlich Windows, Linux und macOS. Die Ursache des Problems könnte eher ein legitimes Sicherheitsrisiko als ein einfacher technischer Fehler sein. In diesem Artikel erklären wir, warum das passiert, was es für die Sicherheit deiner SSH-Verbindung bedeutet und wie du das Problem auf den einzelnen wichtigen Plattformen beheben können.

Was löst die Warnung aus: Die Remote-Host-Identifikation hat sich geändert (und solltest du sich Sorgen machen?)

Die „Warnung: Remote-Host-Identifikation hat sich geändert“ erscheint, wenn der öffentliche SSH-Schlüssel in deinem gespeichert ist bekannte_Hosts Die Datei stimmt nicht mit dem Schlüssel überein, den der Server derzeit präsentiert. Diese Nichtübereinstimmung löst den integrierten Sicherheitsmechanismus von SSH aus, um Sie vor potenziellen Bedrohungen zu schützen.

Legitime Gründe für Host-Schlüsseländerungen

Mehrere harmlose Gründe erklären, warum sich der Hostschlüssel eines Servers ändern könnte. Manchmal siehst du Variationen wie „RSA-Hostschlüssel hat sich geändert“, je nachdem, welcher Schlüsseltyp verwendet wird.

Infografik mit Serveränderungen, die SSH-Hostschlüssel ändern, einschließlich Betriebssystem-Upgrades, Server-Neuerstellungen, Backup-Wiederherstellung, Migration von physisch zu virtuell und Zurücksetzen der SSH-Konfiguration.
Serverbezogene Änderungen:

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

Änderungen der Netzwerkkonfiguration:

Cloud-Anbieter recyceln IP-Adressen im Laufe der Zeit oder deine Verbindungsrouten über einen Load Balancer.
DHCP hat einem anderen Computer eine IP-Adresse zugewiesen
Die IP eines stillgelegten Servers wurde einem neuen System zugewiesen
DNS-Einträge wurden aktualisiert, um auf einen anderen Server zu verweisen

Netzwerkdiagramm, das einen DHCP-Server zeigt, der virtuellen Maschinen dynamische IP-Adressen zuweist, wobei die Außerbetriebnahme und Neuveröffentlichung des Servers zu SSH-Hostschlüsselkonflikten führt.

Wichtige Verwaltungsmaßnahmen:

Aus Sicherheitsgründen haben Systemadministratoren Hostschlüssel manuell neu generiert
Die SSH-Serversoftware wurde neu installiert
Sicherheitsrichtlinien erforderten eine Schlüsselrotation

Es ist wichtig zu wissen, dass Änderungen des Benutzerpassworts keine Auswirkungen auf Hostschlüssel haben. Dabei handelt es sich um separate Authentifizierungsmechanismen. Hostschlüssel ändern sich nur, wenn der Server selbst oder seine SSH-Konfiguration geändert wird.

Wann man die Warnung ernst nehmen sollte

Obwohl viele Hostschlüsseländerungen legitim sind, könnte dies auf eine echte Sicherheitsbedrohung hinweisen. du solltest sich Sorgen machen, wenn:

du hast keine Änderungen am Server vorgenommen und wissen auch nicht, dass Wartungsarbeiten geplant sind
du kannst den Grund für die Schlüsseländerung nicht beim Serveradministrator überprüfen
Der Zugriff auf den Server erfolgt über öffentliche Netzwerke oder nicht vertrauenswürdige Verbindungen
du stellst eine Verbindung zu Produktionssystemen oder Servern her, die vertrauliche Daten enthalten

Geteilter Bildschirm, der legitime SSH-Änderungen in Grün mit Sicherheitsbedrohungsszenarien in Rot vergleicht, mit einer vermummten Figur, die Man-in-the-Middle-Angriffe darstellt.
Man-in-the-Middle-Angriffe kommen zwar relativ selten vor, kommen aber dennoch vor. Bei solchen Angriffen positioniert sich ein Angreifer zwischen deinem Computer und dem legitimen Server und fängt den gesamten Datenverkehr ab.

Menschliches Versagen und Social Engineering sind für 68 % der Sicherheitsverstöße verantwortlich, weshalb Wachsamkeit von entscheidender Bedeutung ist. du kannst deine Systeme weiter schützen, indem du sich darüber informieren Verhinderung von Brute-Force-Angriffen.

Aktuelle Statistiken von IBM zeigen, dass die weltweiten Durchschnittskosten eines Datenschutzverletzung betrug im Jahr 2025 4,44 Millionen US-Dollar, wobei die Erkennungsdauer durchschnittlich acht Monate betrug. Dies zeigt, warum der Hostschlüssel-Überprüfungsmechanismus von SSH existiert und warum Sie diese Warnungen niemals ohne Untersuchung ignorieren sollten.

So überprüfe, ob die Warnung sicher ist

Bevor du das Problem behebst, führe diese Verifizierungsschritte durch:

Flussdiagramm mit fünf Überprüfungsmethoden zur Bestätigung legitimer SSH-Hostschlüsseländerungen, einschließlich Teamberatung, Kontaktaufnahme mit dem Hosting-Anbieter, sicheren Kanälen und Fingerabdruckvergleich.

Erkundigen du dich bei deinem Team: Wenn du den Serverzugriff teilen, frage Kollegen, ob sie Änderungen vorgenommen haben
Überprüfe die Serverprotokolle: Überprüfe Wartungsaufzeichnungen oder Änderungsprotokolle auf aktuelle Aktivitäten
Kontaktieren du deinen Hosting-Anbieter: Überprüfe bei Verwendung von Cloud-Diensten, ob Wartungsarbeiten durchgeführt wurden
Verwende einen sicheren Kanal: Stelle nach Möglichkeit eine Verbindung über ein bekanntermaßen sicheres Netzwerk her, um den Fingerabdruck zu überprüfen
Fingerabdrücke vergleichen: Einige Hosting-Anbieter zeigen in ihren Control Panels aktuelle SSH-Fingerprints an

Wenn du bestätigen können, dass die Schlüsseländerung legitim war, kannst du bedenkenlos mit dem Entfernen des alten Schlüssels und dem Akzeptieren des neuen fortfahren.

Wenn du dynamische IP-Neuzuweisungen oder Hostschlüsselkonflikte vermeiden möchten, spielt die von dir gewählte Infrastruktur eine große Rolle.

Cloudzy bietet SSH-VPS-Hosting mit dedizierten statischen IPs. du laufst auf AMD Ryzen 9-Prozessoren mit NVMe-Speicher für die sofortige Befehlsausführung. Unser Netzwerk erreicht 40 Gbit/s an 12 Standorten weltweit. Darüber hinaus bieten wir kostenlosen DDoS-Schutz, um deine Verbindung sicher zu halten.

So behebst du den Fehler „Remote Host Identification Has Changed“

Die Lösung ist einfach: Entferne den alten Schlüsseldatensatz aus deinem System. Dadurch wird die Nichtübereinstimmung behoben und du kannst den neuen Schlüssel bei der nächsten Verbindung speichern. Schaue sich unseren Leitfaden an SSH-Clients für weitere Werkzeuge.

Darüber hinaus kannst du dies mit einem einzigen Befehl oder durch manuelles Bearbeiten der Datei tun.

Methode 1: Die Befehlszeile (am schnellsten)

Diese Methode funktioniert für macOS, Linux und Windows 10+ (mit OpenSSH). Dies ist der schnellste Weg, den Fehler zu beheben. Weitere Informationen finde im ssh-keygen Manpage.

Öffne dein Terminal.
Führe diesen Befehl aus (ersetze Hostname mit der IP oder Domain deines 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 du einen visuellen Editor bevorzugen, kannst du den Schlüssel selbst löschen. Die Fehlermeldung sagt dir normalerweise genau, welche Zeilennummer entfernt werden muss.

Öffne dein Terminal und bearbeite die Datei mit Nano:

nano ~/.ssh/known_hosts

Suche die Zeile deiner Fehlermeldung. Lösche es und drücke dann Strg + X Und Y zu retten.

Das macOS-Terminalfenster zeigt den geöffneten Nano-Texteditor mit der Datei „known_hosts“, markiert die zu löschende Zeile mit nummerierten Schritten und zeigt Speicheranweisungen an.

Lösung für Windows

Windows-Benutzer verwenden normalerweise entweder den integrierten OpenSSH-Client oder PuTTY.

Option 1: Windows OpenSSH (Windows 10/11)

Unter Windows 10 und 11 ist OpenSSH eine optionale Funktion. Füge es über Einstellungen > Apps > Optionale Funktionen hinzu. Server 2025 enthält den Client, du musst ihn jedoch aktivieren.

Wenn du PowerShell oder die Eingabeaufforderung verwenden, wird die ssh-keygen Der Befehl aus Methode 1 funktioniert auch hier.

Um die Datei stattdessen manuell zu bearbeiten:

Drücken Windows-Taste + R.
Typ %USERPROFILE%\.ssh und drücken Eingeben.
Öffne die bekannte_Hosts Datei mit Notepad.
Lösche die Zeile, die den Fehler verursacht, und speichere die Datei.

Informationen zur ordnungsgemäßen Verwaltung von Schlüsseln finde in unserem Leitfaden unter Generieren von SSH-Schlüsseln in Windows.

Option 2: Verwendung von PuTTY

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

Öffne den Registrierungseditor (Drücke Windows-Taste + R, Typ regedit, und schlagen Eingeben).
Navigiere zu: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys\
Suche den Eintrag, der dem Hostnamen oder der IP deines Servers entspricht.
Klicke mit der rechten Maustaste darauf und wähle aus Löschen.

Der Windows PowerShell-Befehl entfernt den SSH-Hostschlüssel, wobei der Datei-Explorer die aktualisierte Datei „known_hosts“ anzeigt und der PuTTY-Registrierungseditor einen Löschbestätigungsdialog für den Hostschlüssel anzeigt.

Lösung für Linux

Der ssh-keygen Befehl, den wir behandelt haben Methode 1 ist die Standardmethode, um dieses Problem unter Linux zu beheben. Es ist schnell und wird nativ unterstützt.

Manuelle Bearbeitung

Wenn du den Dateiinhalt lieber sehen möchten, kannst du ihn mit einem Texteditor wie Nano bearbeiten.

Öffne dein Terminal.
Typ nano ~/.ssh/known_hosts und drücken Eingeben.
Suche die in deiner Fehlermeldung genannte Zeilennummer.
Lösche die Zeile und drücke dann Strg + X Und Y zu retten.

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

Linux-Terminal mit ssh-keygen-Befehlen zum Entfernen von SSH-Hostschlüsseln nach Hostname und IP-Adresse, mit Erfolgsbestätigung und Beispielen für die Datei „known_hosts“.
Eine Warnung zum Deaktivieren von Prüfungen

du kannst eine SSH-Verbindung ohne Überprüfung erzwingen, dies ist jedoch riskant. Es umgeht den Schutz vor Man-in-the-Middle-Angriffen.

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

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

Unter Windows schlägt der Unix-Pfad fehl. du musst verwenden NULL Damit der Bypass funktioniert:

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

Führe diese Overrides nicht auf öffentlichen Verbindungen oder Live-Servern aus.

Das Beheben von Schlüsselkonflikten gehört zur routinemäßigen Wartung, aber du kannst noch mehr tun, um deine Verbindung zu sichern. Bots zielen häufig mit Brute-Force-Angriffen auf den Standard-Port 22 ab. du kannst die meisten dieser Hintergrundgeräusche vermeiden, indem du SSH-Ports unter Linux ändern zu etwas weniger Vorhersehbarem.

Diagramm eines Man-in-the-Middle-Angriffs auf SSH: Angreifer fängt Client-Server-Verbindung ab, Schlüssel des Angreifers vs. Serverschlüssel, Datendiebstahl und finanzieller Verlust hervorgehoben.

Verwende diese Methode niemals für Produktionsserver oder über nicht vertrauenswürdige Netzwerke.

So verhindre, dass die Meldung „Remote-Host-Identifikation hat sich geändert“ beim nächsten Mal angezeigt wird

Auch wenn du legitime Änderungen des Hostschlüssels nicht immer verhindern können, kannst du Störungen minimieren und bessere Sicherheitspraktiken aufrechterhalten.

Kurzanleitung

deine Rolle	Schlüsselstrategien
Systemadministratoren	Sichre Schlüssel, dokumentiere Änderungen, verwende Zertifikate und rotiere Schlüssel regelmäßig
Regelmäßige Benutzer	Verwalte den Bestand, überprüfe ihn über sichere Kanäle und überwache Protokolle
Cloud-Umgebung Benutzer	Verwende DNS-Namen, nutze Anbietertools und implementierre die Infrastruktur als Code

Infografik mit Best Practices für die SSH-Schlüsselverwaltung: Verwende SSH-Zertifikate, DNS-Namen, Infrastructure as Code, sichre Hostschlüssel, dokumentiere Änderungen und berücksichtige Bastion-Hosts.

Für Systemadministratoren

Hostschlüssel sichern: Schlüssel speichern von /etc/ssh/ bevor du das Betriebssystem neu installieren. Stelle sie anschließend wieder her, um Warnungen für deine Benutzer zu vermeiden.

Geplante Änderungen dokumentieren: Benachrichtige Benutzer, bevor du Schlüssel ändern, und gib die neuen Fingerabdrücke sicher weiter. Dadurch können sie die Verbindung überprüfen.

Verwende SSH-Zertifikate: Große Teams sollten eine zentrale Zertifizierungsstelle nutzen. Dadurch werden Hostschlüssel signiert und eine manuelle Überprüfung entfällt.

Schlüsselrotation implementieren: Plane deine Hostschlüsseländerungen. Vorhersehbare Aktualisierungen sind für dein Team einfacher zu bewältigen als überraschende.

Für regelmäßige Benutzer

Führe ein Inventar: Führe eine persönliche Aufzeichnung der Server-Fingerabdrücke oder nutze die sichere Dokumentation deines Teams.

Überprüfung über Out-of-Band: Bestätige Schlüssel anhand einer vertrauenswürdigen Quelle wie der Cloud-Konsole, nicht anhand zufälliger Nachrichten.

Überwachungsprotokolle: Überprüfe deine lokalen SSH-Protokolle regelmäßig auf ungewöhnliche Verbindungsmuster oder wiederholte Fehler.

Verwende das Konfigurationsmanagement: Verwende SSH-Konfigurationsdateien, um dynamische Entwicklungsumgebungen zu verwalten, ohne die Sicherheitseinstellungen zu verringern.

Für dynamische Cloud-Umgebungen

Verwende DNS-Namen: Stelle eine Verbindung über Hostnamen statt über IPs her. Dadurch bleibt die Konsistenz gewährleistet, wenn sich die zugrunde liegende Adresse ändert.

Nutze Cloud-Tools: Verwende Anbieterkonsolen, um aktuelle Fingerabdrücke abzurufen. Überprüfe die Schlüssel anhand dieser Tools, bevor du Änderungen akzeptieren.

Infrastruktur als Code: Automatisieren du die Schlüsselüberprüfung mit Tools wie Terraform. Für erweiterte Setups kannst du dies auch tun Verwende SSH SOCKS5-Proxys.

Bastion-Gastgeber: Richte Jump-Server mit stabilen Schlüsseln ein. Diese fungieren als sichere Einstiegspunkte zu deiner dynamischen Infrastruktur.

Abschluss

Die „Warnung: Remote-Host-Identifikation hat sich geändert“ dient als wichtiges Sicherheitsmerkmal von SSH und ist kein zu ignorierender Fehler. Obwohl diese Warnung häufig aus legitimen Gründen wie Serverwartung oder Konfigurationsänderungen angezeigt wird, spielt sie eine Schlüsselrolle beim Schutz vor Man-in-the-Middle-Angriffen und unbefugtem Zugriff.

Wenn du auf diese Warnung stoßen, überprüfe die Ursache, bevor du fortfahren. In den meisten Fällen ist die Lösung unkompliziert: Entferne den alten Hostschlüssel mithilfe der für dein Betriebssystem beschriebenen Methoden und akzeptierre dann den neuen Schlüssel bei deiner nächsten Verbindung.

Indem du lernen, wie SSH-Hostschlüssel funktionieren, und Best Practices befolgen, kannst du sowohl Sicherheit als auch Komfort in deinen Remote-Zugriffs-Workflows gewährleisten. Weitere Informationen zum sicheren Übertragen von Dateien finde unter Kopieren von Dateien über SSH.

FAQ

Sollte ich die Warnung ernst nehmen: Die Remote-Host-Identifikation hat sich ernsthaft geändert?

Ja, nimm es ernst. Dies bedeutet, dass sich die Identität des Servers geändert hat, was auf einen Man-in-the-Middle-Angriff oder nur auf routinemäßige Wartungsarbeiten hinweisen könnte. Überprüfe die Änderung immer mit deinem Administrator oder Anbieter, bevor du den neuen Schlüssel akzeptieren, um die Sicherheit zu gewährleisten.

Was verursacht die Warnung „Remote Host Identification Has Changed“?

Diese Warnung tritt auf, wenn der aktuelle Fingerabdruck des Servers nicht mit dem in deiner „known_hosts“-Datei übereinstimmt. Häufige Ursachen sind Neuinstallationen des Betriebssystems, Neuzuweisungen von IP-Adressen oder Zurücksetzen der SSH-Konfiguration. In seltenen Fällen deutet dies auf ein aktives Abfangen eines Man-in-the-Middle-Angriffs hin.

Kann dieser Fehler auf verschiedenen Betriebssystemen auftreten?

Ja, diese Warnung betrifft alle Betriebssysteme, die SSH verwenden, einschließlich Windows, macOS und Linux. Es ergibt sich aus der Sicherheitsüberprüfung des SSH-Protokolls. Während die Reparaturmethoden je nach Plattform variieren, bleibt der zugrunde liegende Sicherheitsauslöser auf jedem System identisch.

Wie erkenne ich, ob die Änderung des Host-Keys legitim oder ein Angriff ist?

Um die Legitimität zu bestätigen, prüfe, ob kürzlich Wartungsarbeiten, Betriebssystemaktualisierungen oder IP-Änderungen durchgeführt wurden. du musst den neuen Fingerabdruck vor dem Herstellen einer Verbindung anhand einer vertrauenswürdigen Quelle überprüfen, z. B. der Konsole deines Cloud-Anbieters oder einer Bestätigung deines Systemadministrators.

Wird SSH durch die Deaktivierung der Host-Schlüsselüberprüfung komfortabler?

Es erhöht den Komfort, verringert jedoch die Sicherheit. Durch das Deaktivieren von Prüfungen wird der Schutz vor Man-in-the-Middle-Angriffen aufgehoben, wodurch Verbindungen anfällig werden. du solltest diese Einstellung nur in isolierten Testumgebungen verwenden, niemals auf Produktionsservern oder öffentlichen Netzwerken mit sensiblen Daten.

Wie oft sollten SSH-Hostschlüssel geändert werden?

Hostschlüssel erfordern im Allgemeinen keine regelmäßige Rotation. Normalerweise solltest du sie nur nach einem Serverneuaufbau, einer Neuinstallation des Betriebssystems oder einer Sicherheitskompromittierung ändern. Häufige Änderungen stören die Benutzer. Gib daher Stabilität und klarer Kommunikation Vorrang, wenn Aktualisierungen erforderlich sind.

Warnung: Remote-Host-Identifikation hat sich geändert und wie du es beheben