Ich versuche, passwortloses SSH auf einem Ubuntu-Server mit ssh-copy-id myuser@myservereinzurichten, erhalte aber den Fehler:
Warnung: Der ECDSA-Hostschlüssel für "myserver" unterscheidet sich vom Schlüssel für die IP-Adresse "192.168.1.123".
Was ist die Ursache und wie behebe ich das? Ich habe versucht, das .sshVerzeichnis auf dem Remotecomputer zu löschen und es ssh-keygen -R "myserver"lokal auszuführen, aber dies behebt den Fehler nicht.
Antworten:
Entfernen Sie den zwischengespeicherten Schlüssel für 192.168.1.123auf dem lokalen Computer:
ssh-keygen -R 192.168.1.123
ssh-keyscan -t ecdsa my.server.domain >> ~/.ssh/known_hostsdanach, dass Sie keinen neuen Schlüssel beim ersten Herstellen einer Verbindung zum Host bestätigen müssen.
In meinem Fall ssh-keygen -R ...hat die Warnung nicht behoben. Ich hatte zusätzliche Informationen wie diese:
Offending key for IP in /home/myuser/.ssh/known_hosts:8
Matching host key in /home/myuser/.ssh/known_hosts:24
Ich habe ~/.ssh/known_hostsZeile 8 (den "beleidigenden Schlüssel") einfach manuell bearbeitet und gelöscht. Ich habe versucht, die Verbindung wiederherzustellen, der Host wurde permanent hinzugefügt, und danach war alles in Ordnung!
sed -e '8d' /home/myuser/.ssh/known_hosts, indem die Zeilennummer 8und der Dateiname durch die auf Ihrem System angezeigten ersetzt werden.
known_hosts:8auf einen nullindexierten Wert bezieht oder nicht. Gut zu wissen, dass es ein 1: 1-Mapping ist ...
ssh-keygen -R [hostname]:2022
Ich arbeite viel zwischen meinen LAN-Computern und meinen beiden Webhosting-Konten. Daher habe ich alle möglichen Probleme mit SSH gelöst, einschließlich Authentifizierungsproblemen, ssh -vum festzustellen, wo und was schief gelaufen ist.
Nachdem ich dieses Problem gerade gelöst hatte und mit den Antworten nicht zufrieden war, wollte ich wirklich wissen, "warum" ich selbst ...
Der Auslöser für meinen Fall ist: Installiertes neues Server-Betriebssystem bei der Arbeit und nach der Installation von openssh-server package wurde ein neuer Satz von Hostschlüsseln auf dem Server von work generiert. Zuvor waren alle meine Server-Betriebssysteme Ubuntu und dieses Mal wurde es auf Debian geändert (und ich vermute, dass es einen nuancierten Unterschied in den Berechtigungen gibt).
Wenn alle Betriebssysteme Ubuntu waren und ich das Betriebssystem eines Servers neu installiere, erhalte ich beim ersten SSH diese Art von Warnung, die ich der stillen Warnung oben vorziehe!
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 ~/.ssh/known_hostsauf dem Computer die ssh, lösche diese Zeile, stelle die Verbindung wieder her 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 Portnummer, von der ich SSH auf der Firewall route
Ich habe die Backups von einem früheren Ubuntu-Server überprüft und mich von meiner neuen Debian-Installation unterschieden:
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 in letzter Zeit angefangen, Ecdsa-Schlüssel zu verwenden. Aufgrund der Änderungen von Ubuntu in letzter Zeit würde ich ein Update dafür verantwortlich machen. Ubuntus Abkehr von dem absolut soliden Linux-Betriebssystem, mit dem ich gerechnet habe, ist der Grund, warum ich dieses Mal Debian installiert habe.
Ich habe eine security.SE-Frage / Antwort auf ecdsa gelesen und diese Zeile bereits von sshd_configmeinem neuen Debian-Server entfernt. (und rannte service ssh restart)
ubuntu debian serverund du wirst sehen, was ich meine.
Die Eingabeaufforderung wird jedes Mal angezeigt, da sich die IP-Adressen bei Verwendung der dynamischen Adressierung ständig ändern. Versuchen Sie, eine statische IP-Adresse zu verwenden, damit Sie den Schlüssel nur einmal hinzufügen müssen.
ssh-keygen -f "/root/.ssh/known_hosts" -R 192.168.1.123
Dies sollte die vorhandenen Schlüssel unter known_hosts.old ersetzen und einen neuen erstellen. Diese Lösung hat bei mir im selben Szenario funktioniert
Ich habe die folgenden Zeilen zu meiner ~ / .ssh / config hinzugefügt, wodurch die strikte Hostprüfung für alle .local-Adressen deaktiviert wurde. (Bei der Zuweisung von DHCP-Adressen ändern sich die IP-Adressen meiner lokalen Computer ständig.)
host *.local
StrictHostKeyChecking no
Sie bekommen trotzdem die Warnung, die mir recht ist.
Verwenden Sie denselben Benutzer für die Verbindung?
Wenn Sie an einem lokalen PC wie Benutzer John angemeldet und mit dem Server B wie Benutzer Adolf @ B verbunden sind und alles in Ordnung ist, bedeutet dies nicht, dass alles in Ordnung ist, wenn Sie an einem lokalen PC wie Benutzer Jane angemeldet sind und eine Verbindung zum Server herstellen B wie Benutzer Adolf @ B .
Wenn Sie sich auf Server B als Benutzer Beda von PC A aus ohne Kennwort anmelden möchten, führen Sie den folgenden Befehl aus, und zwar von PC A aus :
ssh-keygen -t rsa
Dieser Befehl generiert den Schlüssel und speichert ihn in der Datei. Bitte lassen Sie die Passphrase leer.
ssh Beda@B mkdir -p .ssh
Dieser Befehl erstellt das Verzeichnis, sofern es noch nicht vorhanden ist. Andernfalls drucken Sie keine Fehlermeldung.
cd ~/.ssh
Dieser Befehl ändert das Verzeichnis in das Ausgangsverzeichnis Ihres Benutzers ./ssh.
cat id_rsa.pub | ssh Beda@B 'cat >> .ssh/authorized_keys'
Dieser Befehl druckt die Datei id_rsa.pub (Ihren öffentlichen Schlüssel) in authorized_keys auf dem Server.
WICHTIG: Beda ist Ihr Benutzername auf dem Server, mit dem Sie sich verbinden, B ist Ihre Server-IP.
Jetzt können Sie ohne Kennwort oder Kennwortsatz eine Verbindung zum Server B herstellen:
ssh Beda@B
Der Thread hier kann helfen.
Im Wesentlichen möchten Sie sowohl den RSA- als auch den ECDSA-Schlüssel für diesen Host entfernen und dann verwenden ssh-keyscan, um sie auf known_hostseine Weise in Ihre Datei zurückzuspeichern, die diesen Konflikt nicht verursacht. Es hat bei mir funktioniert, als ich das gleiche Problem hatte.
Frage: Was ist der Grund dafür?
Also hat sich der SSH-Server-Hostschlüssel geändert. Was hat die Änderung verursacht? Es ist schwer zu sagen. Hier sind einige Vermutungen:
Frage: ... und wie behebe ich das?
Entfernen Sie, wie andere bereits geantwortet haben, den zwischengespeicherten ECDSA-Hostschlüssel für den von Ihrem Konto zwischengespeicherten MyServer.
Dieser Fehler hat mich lange geärgert. Aus irgendeinem Grund machte es einen Unterschied, ob ich a tun würde
ssh host
oder
ssh host.domain
https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
dann wies mich auf die Möglichkeit hin, die Konfigurationsdatei zu ändern. Siehe meinen Skript https://askubuntu.com/a/949731/129227 es für den Prozess zu automatisieren.
CanonicalizeHostnameund CanonicalDomainskeine strengen Überprüfungen vornehmen, würde ssh dafür sorgen, dass host und host.domain identisch sind.
Ich habe dies auf einem Chromebook durch Deinstallieren und erneutes Installieren von Secure Shell behoben ... Es hat wie ein Zauber funktioniert.
So entfernen Sie einen bekannten Host-Fingerabdruck (aus einer known_hostsDatei) unter Chrome OS:
Suchen Sie den Index des betreffenden Hosteintrags in der ssh-Ausgabe, wenn die Verbindung fehlschlägt. Zum Beispiel ist in der Zeile unter dem beleidigenden Index 7 :
Offending ECDSA key in /.ssh/known_hosts:7
Öffnen Sie die JavaScript-Konsole ( CTRL+ Shift+ J) des Secure Shell-Fensters und geben Sie Folgendes ein. Ersetzen Sie dies INDEXdurch den entsprechenden Wert (z. B. 7 ):
term_.command.removeKnownHostByIndex(INDEX);
Diese Lösung wurde von Leo Gaggls Blog ausgeliehen .
The ECDSA host key for server has changed. Mein Weg ist es, die zugehörige Cache-Zeichenfolge über Domain in zu entfernen~/.ssh/known_hosts. Dann funktioniert der ssh.