Frage Wie man eine Warnung über den ECDSA-Hostschlüssel korrigiert


Ich versuche, passwortloses SSH auf einem Ubuntu-Server mit einzurichten ssh-copy-id myuser@myserver, aber ich bekomme den Fehler:

Achtung: Der ECDSA-Hostschlüssel für 'myserver' unterscheidet sich vom Schlüssel für die IP-Adresse '192.168.1.123'

Was verursacht das und wie behebe ich es? Ich habe versucht, das zu löschen .ssh Verzeichnis auf dem Remote-Computer und läuft ssh-keygen -R "myserver" lokal, aber das behebt den Fehler nicht.


210
2018-05-05 19:05


Ursprung


In meinem Fall ändere ich die Server (ip) -Bindung mit der Domäne, dann die The ECDSA host key for server has changed. Meine Art ist, die zugehörige Cache-Zeichenkette über die Domain zu entfernen ~/.ssh/known_hosts. Dann funktioniert der SSH. - Ninja


Antworten:


Entfernen Sie den zwischengespeicherten Schlüssel für 192.168.1.123 auf dem lokalen Rechner:

ssh-keygen -R 192.168.1.123

302
2018-05-05 20:20



Ich habe bei der Neuinstallation von Debian-Servern bei der Arbeit nicht funktioniert, wenn ich von zuhause aus einen SSH-Server installiert habe. Außerdem ist die Antwort ziemlich knapp. - Chris K
/home/wf/.ssh/known_hosts aktualisiert. Ursprünglicher Inhalt beibehalten als /home/wf/.ssh/known_hosts.old "Warnung: Der ECDSA-Hostschlüssel für die IP-Adresse 'x.x.x.x' wurde dauerhaft zur Liste der bekannten Hosts hinzugefügt." wird angezeigt. und dann scheint es zu funktionieren - Wolfgang Fahl
Sie können den Schlüssel aktualisieren, anstatt ihn zu entfernen. Benutzen ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hosts Danach müssen Sie den neuen Schlüssel bei der ersten Verbindung mit dem Host nicht verifizieren. - Alex
Für die es nicht gelingt, es funktioniert: Ich hatte mehrere Vorkommen der gleichen IP registriert: 1 / die genannte IP-Adresse (xx.xx.xx.xx), Domain (tomsihap.fr), Anbieter gegebenen vps-Server Adresse (vpsxxx.ovh.net). ssh-keygen -R für jeden von ihnen hat die Arbeit gemacht. - tomsihap
Arbeitete für mich, aber die Verwirrung könnte von welchem ​​Host sollte dieser Befehl ausgeführt werden? Die Antwort stammt von der, die den Fehler gezeigt hat. Die zweite Frage und Antwort sind offensichtlicher, aber nur für den Fall: welche Adresse an ssh-keygen -R übergeben? Die Adresse, die in der Fehleranweisung steht. - Russ Bateman


In meinem Fall ssh-keygen -R ... hat die Warnung nicht behoben. Ich hatte zusätzliche Informationen wie folgt:

Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24

Ich habe es einfach manuell bearbeitet ~/.ssh/known_hosts und gelöschte Zeile 8 (der "beleidigende Schlüssel"). Ich habe versucht, wieder zu verbinden, der Host wurde permanent hinzugefügt, und alles war danach gut!


40
2018-03-11 18:52



Das hat für mich funktioniert. Vielen Dank! - Organic Marble
Klappt wunderbar. Kann das in einer Zeile mit beheben sed -e '8d' /home/myuser/.ssh/known_hosts, Ersetzen der Zeilennummer 8 und den Dateinamen mit denen auf Ihrem System angezeigt. - Alex P. Miller


Ich surfe zwischen meinen LAN-Computern und meinen beiden Webhosting-Accounts, also habe ich alle möglichen Kleinigkeiten mit SSH, einschließlich Authentifizierungsproblemen, aussortiert ssh -v um zu sehen, wo und was schief gelaufen ist.

Nachdem ich gerade dieses Problem gelöst und nicht mit den Antworten zufrieden war, wollte ich wirklich selbst "warum" wissen ...

Der Auslöser für meinen Fall ist: installiertes neues Server-Betriebssystem bei der Arbeit und nach der Installation des openssh-server-Pakets wurde ein neuer Satz von Host-Schlüsseln auf dem Arbeitsserver erzeugt. Zuvor waren alle meine Server-Betriebssysteme Ubuntu und dieses Mal wechselte es zu Debian (und ich vermute, dass es einen differenzierten Unterschied in den Berechtigungen gibt).

Wenn alle Betriebssysteme Ubuntu waren und ich das Betriebssystem eines Servers neu installiere, bekomme ich nach dem ersten SSH eine solche Warnung, was ich vor der obigen stummen Warnung bevorzuge!

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
06:ea:f1:f8:db:75:5c:0c:af:15:d7:99:2d:ef:08:2a.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:4
RSA host key for domain.com has changed and you have requested strict checking.
Host key verification failed.

Dann öffne ich mich ~ / .ssh / bekannte_Hosts Auf dem Computer, der den ssh initiiert, lösche diese Zeile, reconnect und das passiert:

chris@home ~ $ ssh work
The authenticity of host '[work]:11122 ([99.85.243.208]:11122)' can't be established.
ECDSA key fingerprint is 56:6d:13:be:fe:a0:29:ca:53:da:23:d6:1d:36:dd:c5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[work]:11122 ([99.85.243.208]:11122)' (ECDSA) to the list of known hosts.
Linux rock 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64

Das bisschen über: 11122 ist die Port-Nummer, die ich SSH von der Firewall aus route

Ich überprüfte Backups von einem früheren Ubuntu-Server und diffdierte gegen meine neue Debian-Installation:

Ubuntu:                                            Debian:
# Package generated configuration file             # Package generated configuration file
# See the sshd(8) manpage for details              # See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for      # What ports, IPs and protocols we listen for
Port 22                                            Port 22
# Use these options to restrict which interface    # Use these options to restrict which interfaces
#ListenAddress ::                                  #ListenAddress ::
#ListenAddress 0.0.0.0                             #ListenAddress 0.0.0.0
Protocol 2                                         Protocol 2
# HostKeys for protocol version 2                  # HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key                  HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key                  HostKey /etc/ssh/ssh_host_dsa_key
------------------------------------------------   HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security    #Privilege Separation is turned on for security
UsePrivilegeSeparation yes                         UsePrivilegeSeparation yes

Also ja, wahrscheinlich hat der Host kürzlich Ecdsa-Schlüssel verwendet, was aufgrund der Änderungen von Ubuntu in letzter Zeit auf ein Update zurückzuführen ist. Ubuntus Abkehr von dem grundsoliden Linux-Betriebssystem, auf das ich zählte, ist der Grund, warum ich dieses Mal Debian installiert habe.

ich lese ein security.SE q / a auf Ecdsa und habe diese Zeile bereits entfernt sshd_config mein neuer Debian-Server. (und rannte service ssh restart)


14
2018-01-16 08:12



+1 für den schönen Seite-an-Seite-Vergleichsblock. Könntest du eine URL hinzufügen, die klarstellt, dass "Ubuntus Abkehr vom grundsoliden Linux-Betriebssystem" bedeutet? - bgoodr
@bgoodr ist meiner Meinung nach einzig und allein auf die Einrichtung eines eigenen RAID-Fileservers in den letzten Jahren zurückzuführen. : / Mist als Antwort, aber fang an zu googeln ubuntu debian server und du wirst sehen, was ich meine. - Chris K
@ChrisK Sie, Herr, sind ein Chef. Danke für die detaillierte, aber knappe Antwort. - sargas


ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123

Dies sollte die vorhandenen Schlüssel unter known_hosts.old ersetzen und eine neue erstellen. Diese Lösung funktionierte für mich im selben Szenario


5
2018-05-14 18:16





Die Eingabeaufforderung tritt jedes Mal auf, da sich die IP-Adressen bei Verwendung der dynamischen Adressierung ständig ändern. Versuchen Sie, statische IP-Adresse zu verwenden, sodass Sie den Schlüssel nur einmal hinzufügen müssen.


4
2018-01-16 09:06



Guter Punkt, habe ich vermisst, wo jemand dynamische ips erwähnt? - Chris K


Verwenden Sie denselben Benutzer für die Verbindung?

Wenn Sie bei einem lokalen PC wie Benutzer angemeldet sind John und mit dem Server verbunden B wie ein Benutzer Adolf @ B und alles ist in Ordnung, es bedeutet nicht, dass alles in Ordnung ist, wenn Sie auf dem lokalen PC wie Benutzer angemeldet sind Jane und Verbindung mit dem Server B wie ein Benutzer Adolf @ B.

Wenn Sie sich als Benutzer Beda vom PC auf Server B einloggen wollen EIN ohne Passwort, versuchen Sie diesen Befehl, alles vom PC aus EIN:

ssh-keygen -t rsa

Dieser Befehl generiert den Schlüssel und speichert den Schlüssel in der Datei. Bitte geh Passphrase leer.

ssh Beda@B mkdir -p .ssh

Dieser Befehl erstellt das Verzeichnis, falls es nicht bereits existiert. Andernfalls drucken Sie keine Fehlermeldung.

cd ~/.ssh

Dieser Befehl ändert das Verzeichnis in das Ausgangsverzeichnis Ihrer Benutzer ./ssh.

cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'

Dieser Befehl druckt die Datei id_rsa.pub (Ihr öffentlicher Schlüssel) in authorized_keys auf dem Server.

WICHTIG: Beda ist Ihr Benutzername auf dem Server, den Sie verbinden, B ist Ihre Server-IP.

Jetzt können Sie sich ohne Passwort oder Passphrase mit dem Server B verbinden:

ssh Beda@B

2
2017-10-21 09:17



Oder verwenden Sie einfach ssh-copy-id, um eine authorized_keys-Datei mit Ihrem id_rsa.pub-Schlüssel aufzufüllen, ohne den ganzen zusätzlichen Aufwand. - BlakBat


Der Faden Hier kann helfen.

Im Wesentlichen möchten Sie sowohl die RSA- als auch die ECDSA-Schlüssel für diesen Host entfernen und anschließend verwenden ssh-keyscan um sie wieder in dich zu legen known_hosts Datei auf eine Weise, die diesen Konflikt nicht verursacht. Es funktionierte für mich, als ich das gleiche Problem hatte.


1
2017-12-20 16:47





Frage: Was verursacht das, ...?

Also der SSH-Server-Host-Schlüssel geändert. Was hat die Veränderung verursacht? Es ist schwer zu sagen. Hier sind einige Vermutungen:

  • Hat sshd auf meinem Server ECDSA-Schlüssel verwendet, also ist es ein neuer Schlüsseltyp?
  • Wurde myserver kürzlich neu installiert?
  • Wurde sshd kürzlich auf meinem Server neu installiert, so dass ein neuer ssh-Hostschlüssel generiert wurde?
  • Hat jemand den sshd-Hostschlüssel neu generiert oder ersetzt?
  • Hat sich die IP-Adresse von myserver geändert, sodass ein anderer Host auf diese IP-Adresse antwortet?

Frage: ... und wie repariere ich es?

Wenn andere bereits geantwortet haben, entfernen Sie den zwischengespeicherten ECDSA-Hostschlüssel für meinen Server, den Ihr Konto zwischengespeichert hat.


1
2017-08-07 15:42



Guter Rat, beantwortet die Frage aber nicht. Versucht nicht einmal, die Frage zu beantworten. - boatcoder