Die Identifikation des SSH-Remote-Hosts hat sich geändert


619

Ich habe meinen Server neu installiert und erhalte folgende Meldungen:

[user@hostname ~]$ ssh root@pong
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 RSA key sent by the remote host is
6e:45:f9:a8:af:38:3d:a1:a5:c7:76:1d:02:f8:77:00.
Please contact your system administrator.
Add correct host key in /home/hostname /.ssh/known_hosts to get rid of this message.
Offending RSA key in /var/lib/sss/pubconf/known_hosts:4
RSA host key for pong has changed and you have requested strict checking.
Host key verification failed.

Ich habe verschiedene Lösungen ausprobiert, die ich im Internet gefunden habe. Meine known_hostsDatei (normalerweise in ~/.ssh/known_hosts) ist in /var/lib/sss/pubconf/known_hosts. Ich habe versucht, es zu bearbeiten, aber es bleibt in einem Zustand. Ich habe ipa-client installiert und habe Fedora 19. Wie löse ich diese Warnung?

Alle bisher beantworteten Antworten funktionieren nur, wenn Sie Freeipa nicht installiert haben.

Die richtige Antwort für freeipa in den Kommentaren unten von adrin ist hier .



1
Hier gibt es einen Stillstand. Dieser ist doppelt markiert, damit niemand eine Antwort hinzufügen kann, und derjenige, den er verknüpft, ist vom Thema getrennt, sodass dort auch keine Antwort hinzugefügt werden kann. Wenn Sie die bekannten_Hosts löschen, wird das Problem ebenfalls behoben.
Zar

1
Ich hatte das gleiche Problem. Aus Gründen der Mine und anderen, hier ist die Frage , und meine Antwort darauf: superuser.com/questions/1071204/...
adrin

3
Als jemand, der zuerst seinen Schlüssel überprüfen wollte, fand ich diese Antwort nützlich. askubuntu.com/a/83499/620623
Declan McKenna

Wie Sharrajesh erwähnt: Überprüfen Sie Ihre DNS-Einträge (in FreeIPA für mich) und stellen Sie fest, dass Sie nicht mehrere A-Einträge mit IPs haben, die über das Netzwerk nicht erreichbar sind.
th3penguinwhisperer

Antworten:


1071

Hier ist die einfachste Lösung

ssh-keygen -R <host>

Zum Beispiel,

ssh-keygen -R 192.168.3.10

Von der ssh-keygenManpage :

  • -R hostnameEntfernt alle zum Hostnamen gehörenden Schlüssel aus einer Datei "unknown_hosts". Diese Option ist nützlich, um Hash-Hosts zu löschen (siehe die Option -H oben).

Ich bin unter Windows und diese Lösung, noch funktioniert das Entfernen von Schlüsseln. Was kann ich noch versuchen?
Jaycode

5
Okay, es stellt sich heraus, dass ich unter Windows ein Terminal von Git Bash (oder ein beliebiges MingW32-Terminal) verwenden muss. Tricky.
Jaycode

25
Beachten Sie, dass Sie bei einer Verbindung über einen bestimmten Port möglicherweise eine Syntax entfernen müssen ssh-keygen -R [127.0.0.1]:3022. Überprüfen Sie einfach Ihre .ssh / unknown_hosts-Datei auf explizite Angaben.
Adam Johns

4
Wenn ich dies versuche, erhalte ich den Fehler "<Hostname> nicht in ~ / .ssh / unknown_hosts gefunden"
Nodeocrat

3
Warum tritt diese Warnung auf?
Vilas Joshi

199

Verwenden

ssh-keygen -R [hostname]

Beispiel mit einer IP-Adresse / einem Hostnamen wäre:

ssh-keygen -R 168.9.9.2

Dadurch wird die Beleidigung Ihres Hosts von den bekannten Hosts aktualisiert. Sie können den Pfad der bekannten_Hosts auch mit dem Flag -f versehen.


1
Entsprechenden Schlüssel entfernen $ ssh-keygen -R {server.name.com}| $ ssh-keygen -R {ssh.server.ip.address}| $ ssh-keygen -R server.example.com
DaddyMoe

5
Wie bekommt eine Antwort ohne Erklärung so viele positive Stimmen? Keine Sicherheitsbedenken, keine Erklärung. -1
Daniel W.

4
Es scheint auch wie eine Kopie der anderen Antwort unten. Bitte ein Mod dieses Chaos aufräumen ...
Daniel W.

115

Ich hatte den gleichen Fehler, nachdem ich ein Digital Ocean Ubuntu-Image neu erstellt hatte. Ich habe den folgenden Befehl mit meiner Server-IP anstelle von verwendet[IP_ADDRESS]

ssh-keygen -R [IP_ADDRESS]

Ich danke dir sehr! Ich habe den Hostnamen verwendet und es hat nur mit der IP_ADDRESS funktioniert :)
J. Lopes

1
Dies hat es für mich getan und sollte die akzeptierte Antwort sein. Ich weiß nicht, warum es zwei Kopien dieser Antwort gibt, die später kamen und beide mehr positive Stimmen haben.
Wylliam Judd

Dein war nicht der gleiche Fehler; Auf Ihrem Server wurde keine SSSD ausgeführt. Siehe OP.
Mercury00

39

Wenn Sie den Server neu installieren, ändert sich seine Identität und Sie erhalten diese Meldung. Ssh kann nicht wissen, ob Sie den Server geändert haben, mit dem es verbunden ist, oder ob Ihrem Netzwerk ein Server in der Mitte hinzugefügt wurde, um Ihre gesamte Kommunikation zu überwachen. Dies macht Sie darauf aufmerksam.

Entfernen Sie einfach den Schlüssel aus bekannten_Hosts, indem Sie den entsprechenden Eintrag löschen:

sed '4d' -i /var/lib/sss/pubconf/known_hosts

Das 4dist auf Rechnung vonOffending RSA ...known_hosts:4


1
Danke, aber ich weiß nicht warum, aber ich entferne es und es ist wieder drin. Ich habe versucht, den SSD-Dienst zu beenden, und dieser Effekt ist verschwunden, aber nach dem Starten von SSD wird er erneut angezeigt.
Filip Dobrovolný

Sichern Sie Ihr ~ / .ssh-Verzeichnis und löschen Sie es dann. Fügt Ihr Dienst die Schlüssel immer wieder hinzu, nachdem ~ / .ssh weggeblasen wurde?
Mockinterface

Ich habe .ssh in .ssh_old umbenannt. Nach einem neuen Verbindungsversuch erstellen Sie einfach das leere Verzeichnis .ssh. Und ich kann / var / lib / sss / pubconf / unknown_hosts immer noch nicht "editierbar" machen.
Filip Dobrovolný

4
Der tragbarere Weg, dies zu tun: sed -i -e 4d /var/lib/sss/pubconf/known_hosts
Pierz

2
Wie sichern Sie die Server für identificationden Fall, dass Sie den Server neu erstellen möchten, ohne Störungen wie diese Fehlermeldung zu verursachen?
Ninjaxor

38

Der Vorschlaghammer soll jeden bekannten Wirt auf einen Schlag entfernen:

rm ~/.ssh/known_hosts

Ich stoße darauf, da wir kleine Subnetze kurzlebiger Server aus einer Sprungbox verwenden und häufig interne IP-Adressen von Servern wiederverwenden, die denselben SSH-Schlüssel verwenden.


Arbeitete für mich auf einer vagabundierenden VM, als die akzeptierte Antwort nicht funktionierte.
100pic

1
Nützliches Werkzeug im Gürtel, aber dies könnte Sie für einen MitM-Angriff öffnen (genau das, was known_hostsverhindert werden soll). Tun Sie dies nur, wenn Sie sicher sind, dass alle Hosts dort sicher sind.
Freedom_Ben

26

Das Problem ist, dass Sie zuvor eine SSH-Verbindung zu einem Remotecomputer akzeptiert haben und sich der digitale Fingerabdruck oder der SHA256-Hash-Schlüssel des Remotecomputers seit Ihrer letzten Verbindung geändert hat. Wenn Sie also erneut versuchen, SSH zu verwenden, oder Github verwenden, um Code abzurufen, der auch SSH verwendet, wird eine Fehlermeldung angezeigt. Warum? Weil Sie dieselbe Remotecomputeradresse wie zuvor verwenden, der Remotecomputer jedoch mit einem anderen Fingerabdruck reagiert. Daher ist es möglich, dass jemand den Computer fälscht, mit dem Sie zuvor verbunden waren. Dies ist ein Sicherheitsproblem.

Wenn Sie zu 100% sicher sind, dass der Remotecomputer nicht kompromittiert, gehackt, gefälscht usw. wird, müssen Sie lediglich den Eintrag in Ihrer Datei "unknown_hosts" für den Remotecomputer löschen. Dadurch wird das Problem behoben, da beim Herstellen der Verbindung keine Nichtübereinstimmung mit den SHA256-Fingerabdruck-IDs mehr besteht.

Auf dem Mac habe ich Folgendes getan:

1) Suchen Sie die Ausgabezeile, die lautet. RSA host key for servername:port has changed and you have requested strict checking.Sie benötigen sowohl den Servernamen als auch den potenziellen Port dieser Protokollausgabe.

2) Sichern Sie die bekannte SSH-Hosts-Datei cp /Users/yourmacusername/.ssh/known_hosts /Users/yourmacusername/.ssh/known_hosts.bak

3) Suchen Sie die Zeile, in der der alte Fingerabdruck des Computers gespeichert ist, und löschen Sie ihn. Sie können anhand des Servernamens und des Ports aus Schritt 1 nach dem spezifischen Fingerabdruck des betreffenden Remotecomputers suchen.nano /Users/yourmacusername/.ssh/known_hosts

4) STRG-X zum Beenden und Y zum Speichern von Änderungen auswählen

Geben ssh -p port servernameSie nun ein und Sie erhalten die ursprüngliche Eingabeaufforderung, die Sie beim ersten Versuch, SSH auf diesen Computer zu senden, ausgeführt haben. Sie haben dann die Möglichkeit, den aktualisierten SHA256-Fingerabdruck des Remotecomputers in Ihrer Datei "unknown_hosts" zu speichern. Wenn Sie SSH über Port 22 verwenden, ist das Argument -p nicht erforderlich.

Bei Problemen können Sie die ursprüngliche Datei "unknown_hosts" wiederherstellen: cp /Users/yourmacusername/.ssh/known_hosts.bak /Users/yourmacusername/.ssh/known_hosts


3
Das sollte als akzeptierte Antwort markiert werden. Das Befolgen dieser Schritte hat mein Problem behoben, obwohl ssh-keygen -R [IP_ADDRESS]es bei mir nicht funktioniert hat. Vielen Dank!
Yusuf Kamil AK

Ja, einer dieser Fälle ist nicht fair, die beste Antwort sicher. Die 2. und 3. Antwort wiederholen nur das, was die 1. Antwort gesagt hat, und alle haben eine unvollständige Lösung.
brasofilo

16

Wie viele bereits gesagt haben, verwenden Sie ssh-keygen, dh

ssh-keygen -R pong

Möglicherweise möchten Sie auch die Überprüfung des Hostschlüssels vorübergehend deaktivieren:

ssh -oStrictHostKeyChecking=no root@pong

Was ich für die .ssh / config verwende : Host ???? CheckHostIP no StrictHostKeyChecking no(3 Zeilen, tabellarisch ab dem 2.)
XXL

15

Funktioniert bei mir!

Fehler: Beleidigender RSA-Schlüssel in / var / lib / sss / pubconf / unknown_hosts: 4

Dies zeigt an, dass Sie in Zeile Nr. 1 einen fehlerhaften RSA-Schlüssel haben. 4

Lösung 1 :

1. vi /var/lib/sss/pubconf/known_hosts

2 remove line no: 4 ..

3. Save and Exit, and Retry .

Lösung 2:

ssh-keygen -R "you server hostname or ip"

ODER

Lösung 3:

sed -i '4d' /root/.ssh/known_hosts

Dadurch wird die 4thZeile von /root/.ssh/known_hostsin place ( -i) entfernt.


1
Dies funktioniert für die .ssh-Datei unknown_hosts von root. Nicht für / var / lib / sss / pubconf / unknown_hosts, eine von SSSD verwaltete Datei, die von einem Remote-Server gefüllt wird.
Mercury00

1
In meinem Fall ist das Problem aus irgendeinem Grund bei bekannten_Hosts * 2 * aufgetreten. Das Befolgen dieser Schritte hat mir geholfen, das herauszufinden, danke @Sahil Gulati!
Lucas

11

Ich habe die Lösung von mockinterface verwendet, obwohl das sed-i nicht ganz funktioniert hat. Ich habe es gelöst, indem ich die Zeile von Hand mit vim gelöscht habe:

sudo vim /var/lib/sss/pubconf/known_hosts

Sie können jeden anderen gewünschten Texteditor verwenden, müssen jedoch möglicherweise Ihre Administratorrechte angeben


1
Ja, das Löschen des Datensatzes derselben IP in der Datei unknown_hosts behebt das Problem.
Wobei

Der Eintrag wird sofort von SSSD neu erstellt, wenn erneut versucht wird, ssh auszuführen. Beachten Sie, dass sss pubconf unknown_hosts eine verwaltete Datei ist und kein lokales Repository, das vom lokalen Server gefüllt wird.
Mercury00

9

Für Mac-Benutzer können Sie das -RFlag des ssh-keygenBefehls verwenden. Kurzes Beispiel:

ssh-keygen -R THE_IP_ADDRESS

THE_IP_ADDRESSDies ist die IP, in die Sie ssh versuchen. Und dann können Sie gut verbinden.


8

Dies liegt daran, dass sich die Einstellungen Ihres Remotecomputers geändert haben. Entfernen Sie dazu Ihre aktuellen Schlüssel.

vim /root/.ssh/known_hosts

Löschen Sie die Zeile der IP, die Sie verbinden.


7

Bearbeiten /home/hostname /.ssh/known_hostsund löschen Sie die 4 Zeilen und speichern Sie sie.

Führen ssh root@pongSie es dann erneut aus. Die folgende Meldung wird angezeigt: Are you sure you want to continue connecting (yes/no)? yesEinfach ausdrucken yes.

Hinweis: Wenn Sie ein Problem haben, lesen Sie zuerst die Hinweise, es wird helfen.


Beste Antwort, die tatsächlich erklärt, was los ist.
Prometheus

6

Die anderen Antworten hier sind gut und trotzdem habe ich das Problem durch Löschen gelöst ~/.ssh/known_hosts. Dies löst sicherlich das Problem, aber es ist wahrscheinlich nicht der beste Ansatz.


6

In meinem Fall geschah dies, weil ich zuvor eine SSH-Verbindung mit einem Computer mit derselben IP (z. B. 192.152.51.10) hatte und das System den RSA-Schlüssel (gespeichert in /home/user_name/.ssh/known_hosts) des vorherigen Hosts berücksichtigte in Nichtübereinstimmung.

Um dieses Problem zu beheben , müssen Sie den zuvor gespeicherten RSA-Schlüssel für die IP 192.152.51.10 entfernen .

ssh-keygen -f "/home/user_name/.ssh/known_hosts" -R 192.152.51.10

5

Einfache Einzeilerlösung, getestet auf dem Mac:

sed '/212.156.48.110/d' ~/.ssh/known_hosts > ~/.ssh/known_hosts

Löscht nur die Ziel-SSH-Host-IP von bekannten Hosts.

Dabei wird 212.156.48.110 durch die Ziel-Host-IP-Adresse ersetzt.

Ursache : Es ist aufgetreten, weil die Ziel-IP aufgrund der Portweiterleitung bereits für einen anderen Computer bekannt war. Durch Löschen der Ziel-IP vor dem Herstellen der Verbindung wird das Problem behoben.


4

Verwenden Sie diesen Befehl:

truncate -s 0 /home/SYSTEM_NAME/.ssh/known_hosts

Bitte fügen Sie eine Erklärung hinzu, was der Befehl tut und was nicht.
Daniel W.

6
Warum sollten Sie die Datei abschneiden wollen? Sie verlieren alle Informationen, auch die Informationen, die Sie bereits überprüft haben. Dies ist eine schlechte Methode, um gegen einen einzelnen geänderten öffentlichen Hostschlüssel vorzugehen.
Daniel W.

1
Dies ist ein totaler Hack: D, aber es funktioniert: D
Benjamin

Hinweis: Dadurch werden auch alle anderen Hostinformationen gelöscht. Wenn Sie automatisierte Skripts von Ihrem Computer ausführen (z. B. Bereitstellungen), können diese beschädigt werden, da Sie alle Hostschlüssel manuell erneut bestätigen müssen. Nur um andere Benutzer hier zu warnen, die die einfachste Lösung verwenden möchten.
Mateng

3

Entfernen Sie den Eintrag aus bekannten_Hosts mit:

ssh-keygen -R *ip_address_or_hostname*

Dadurch wird die problematische IP- Adresse oder der problematische Hostname aus der Datei " unknown_hosts " entfernt und erneut versucht, eine Verbindung herzustellen .

Aus den Manpages:

-R hostname
Entfernt alle zum Hostnamen gehörenden Schlüssel aus einer Datei "unknown_hosts". Diese Option ist nützlich, um Hash-Hosts zu löschen (siehe die Option -H oben).


3

Mach einfach:

cd /home/user/.ssh/-> hier userist /home/jon/zum Beispiel Ihr Benutzername .

Dann

gedit known_hosts & und löschen Sie den Inhalt darin.

Jetzt sshsollte es wieder funktionieren.


3

Wenn Sie versuchen, mit dem Befehl eine Verbindung zum laufenden Docker-Container auf Port 2222 herzustellen, wird der Fehler angezeigt

mian@tdowrick2~$ ssh pos@localhost -p 2222

Um dieses Problem zu lösen, gehen Sie auf Ihrem lokalen Computer (dh Host-Computer nicht Container) zu cd ~/.ssh/und öffnen Sie die known_hostsDatei mit dem Texteditor. Entfernen Sie die Zeile beginnend mit [localhost]:2222und speichern Sie die Datei. Versuchen Sie nun erneut, ssh

mian@tdowrick2~$ ssh pos@localhost -p 2222

Der Fehler verschwindet, aber Sie müssen ihn jedes Mal neu starten, wenn der Container neu gestartet wird.


2

Meine Lösung ist:

  1. vi ~/.ssh/known_hosts
  2. Löschen Sie die Zeile, die Ihre gewünschte IP-Adresse enthält.

Dies ist besser als alle zu löschen known_hosts


Dies ist die gleiche Antwort wie bei miota85 unten.
Daniel W.

2

Einziges clientseitiges Problem (doppelter Schlüssel für IP):

Varianten lösen:

Für eine eindeutige IP-Adresse (Standardport 22):

ssh-keygen -f -R 7.7.7.7

Für eine IP ( nicht Standardport ):

ssh-keygen -f -R 7.7.7.7:333

Schnell alle ips löschen:

cd ~; rm .ssh/known_hosts

7.7.7.7 - SSH Ihre Server-IP-Verbindung

333 - Nicht-Standard-Port


2

Manchmal, wenn Sie aus irgendeinem Grund einen Server neu installieren müssen, stellen wir bei der Verbindung über ssh fest, dass Ihr Server angibt, dass sich die Identifikation geändert hat. Wenn wir wissen, dass es sich nicht um einen Angriff handelt , sondern dass wir das System wiederhergestellt haben, können wir die alte Identifikation mit ssh-keygen von den bekannten_Hosts entfernen:

ssh-keygen -R <host/ip:hostname>
root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old

Wenn Sie erneut eine Verbindung herstellen, werden Sie aufgefordert, den neuen Fingerabdruck zu validieren:

ssh -l user <host/ip:hostname>
The authenticity of host '<host/ip:hostname>' can't 
be established.
RSA key fingerprint is 3f:3d:a0:bb:59:24:35:6d:e5:a0:1a:3f:9c:86:81:90.
Are you sure you want to continue connecting (yes/no)? yes

1

Ich hatte dieses Problem und der Grund ist sehr einfach. Ich habe eine doppelte IP-Adresse für die SSH-Anmeldung. Nachdem Sie dieses Problem geändert haben, ist alles gelöst.


1

Ich hatte den gleichen Fehler auf meinem Computer und lösche die known_hostsDatei. Danach funktioniert sie einwandfrei.


1
Sie möchten Ihre nicht löschen, authorized_keyswenn Sie ein Problem mit der known_hostsDatei haben
jeb

0

LÖSUNG:

1- Löschen Sie aus "$ HOME / .ssh / unknown_hosts" die Zeile, die sich auf den Host bezieht, zu dem keine Verbindung hergestellt werden kann.

2- Führen Sie diesen Befehl aus: ssh-keygen -R "IP_ADDRESSorHOSTNAME" (ersetzen Sie "IP_ADDRESSorHOSTNAME" durch Ihre Ziel-IP oder Ihren Ziel-Hostnamen)

3- Wiederholen Sie die SSH-Verbindung (wenn dies fehlschlägt, überprüfen Sie bitte die Berechtigung im SSH-Verzeichnis. Es muss 700 sein.)


0

Meine Lösung unter UBUNTU (Linux):

1. Sie müssen den Inhalt aus der Datei "unknown_hosts" löschen, die sich in "/home/YOUR_USERNAME/.ssh/known_hosts" befindet.

2.Erstellen Sie einen neuen SSH-Schlüssel wie "ssh-keygen -t rsa -C" your.email@example.com "-b 4096".

3. Kopieren Sie Ihren neuen SSH-Schlüssel in Ihr SSH-Repository (in meinem Fall Gitlab) und fügen Sie SSH-Schlüssel ein.

Für mich geht das !


-1

AWS EC2.

Finden Sie die IP in der Nachricht, die es Ihnen gibt.

Lauf

vim /home/ec2-user/.ssh/known_hosts

Verwenden Sie die Pfeiltasten, um die IP-Adresse in der Nachricht zu finden, und klicken Sie auf.

dd

Dadurch wird diese Zeile gelöscht und Escape ausgeführt

:wp

Dies spart, dann können Sie loslegen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.