ssh: Die Authentizität des Hosts 'Hostname' kann nicht ermittelt werden

Question

Wenn ich an eine Maschine ssh bin, bekomme ich manchmal diese Fehlermeldung und es wird aufgefordert, "Ja" oder "Nein" zu sagen. Dies führt zu Problemen bei der Ausführung von Skripten, die automatisch an andere Maschinen gesendet werden.

Warnung Nachricht:

The authenticity of host '<host>' can't be established. 
ECDSA key fingerprint is SHA256:TER0dEslggzS/BROmiE/s70WqcYy6bk52fs+MLTIptM. 
Are you sure you want to continue connecting (yes/no)? yes 
Warning: Permanently added 'pc' (ECDSA) to the list of known hosts. 

Gibt es eine Möglichkeit dies automatisch mit „Ja“ oder ignorieren zu sagen?

Answer 1

Abhängig von Ihrem ssh-Client können Sie die StrictHostKeyChecking-Option in der Befehlszeile auf no setzen und/oder den Schlüssel an eine leere known_hosts-Datei senden. Sie können diese Optionen auch in Ihrer Konfigurationsdatei festlegen, entweder für alle Hosts oder für einen bestimmten Satz von IP-Adressen oder Hostnamen.

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no 

EDIT

Als @IanDunn Notizen gibt es Sicherheitsrisiken, dies zu tun. Wenn die Ressource, zu der Sie eine Verbindung herstellen, von einem Angreifer gefälscht wurde, kann sie die Herausforderung des Zielservers möglicherweise erneut an Sie weitergeben und Sie glauben lassen, dass Sie eine Verbindung mit der Remote-Ressource herstellen, während sie tatsächlich eine Verbindung zu dieser Ressource herstellen Ihre Anmeldeinformationen. Sie sollten sorgfältig abwägen, ob dies ein angemessenes Risiko darstellt, bevor Sie Ihren Verbindungsmechanismus ändern, um HostKeyChecking zu überspringen.

Reference.

Answer 2

Im Allgemeinen tritt dieses Problem auf, wenn Sie die Schlüssel sehr häufig ändern. Basierend auf dem Server kann es einige Zeit dauern, den neuen Schlüssel zu aktualisieren, den Sie generiert und auf dem Server eingefügt haben. Warten Sie nach dem Generieren des Schlüssels und Einfügen auf dem Server 3 bis 4 Stunden und versuchen Sie es dann. Das Problem sollte gelöst werden. Es ist mir passiert.

Answer 3

deaktivieren (oder Steuer Sperrung), fügen Sie die folgenden Zeilen am Anfang von /etc/ssh/ssh_config ...

Host 192.168.0.* 
    StrictHostKeyChecking=no 
    UserKnownHostsFile=/dev/null 

Optionen:

• Das Host-Subnetz * sein können uneingeschränkten Zugang zu ermöglichen alle IPs.
• Bearbeiten Sie /etc/ssh/ssh_config für globale Konfiguration oder ~/.ssh/config für benutzerspezifische Konfiguration.

Siehe http://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

ähnliche Frage auf superuser.com - siehe https://superuser.com/a/628801/55163

Answer 4

ich das Problem lösen, das unten geschrieben Fehler gibt:
Fehler:
die Echtheit des Wirtes XXX.XXX. XXX 'kann nicht festgestellt werden.
RSA-Schlüssel Fingerabdruck ist 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89.

Lösung:
1. Installieren Sie ein openSSH-Tool.
2. run command ssh
3. es wird nach fragen Sie fügen diesen Host wie hinzu. JA akzeptieren.
4.Dieser Host fügt die bekannte Hostliste hinzu.
5. Jetzt können Sie eine Verbindung mit diesem Host herstellen.

Diese Lösung arbeitet jetzt ......

Answer 5

Stellen Sie sicher, ~/.ssh/known_hosts beschreibbar ist. Das hat es für mich behoben.

Answer 6

Der beste Weg, dies zu erreichen, ist die Verwendung von 'BatchMode' zusätzlich zu 'StrictHostKeyChecking'. Auf diese Weise akzeptiert Ihr Skript einen neuen Hostnamen und schreibt ihn in die Datei "known_hosts", erfordert jedoch keine Ja/Nein-Intervention.

ssh -o BatchMode=yes -o StrictHostKeyChecking=no user@server.example.com "uptime" 

Answer 7

Alte Frage, die eine bessere Antwort verdient.

Sie können eine interaktive Eingabeaufforderung verhindern, ohne StrictHostKeyChecking zu deaktivieren (was unsicher ist).

Integrieren Sie die folgende Logik in das Skript:

if [ -z `ssh-keygen -F $IP` ]; then 
    ssh-keyscan -H $IP >> ~/.ssh/known_hosts 
fi 

Es prüft, ob öffentliche Schlüssel des Servers in known_hosts ist. Wenn nicht, fordert es den öffentlichen Schlüssel vom Server an und fügt ihn zu known_hosts hinzu.

Auf diese Weise können Sie nur einmal zu Man-In-The-Middle-Angriff ausgesetzt sind, die durch gemildert werden kann:

• sicherzustellen, dass das Skript
• Inspektion Protokolle erstmals über einen sicheren Kanal verbindet oder known_hosts Fingerabdrücke zu überprüfen manuell (nur einmal durchgeführt werden)

Answer 8

Bearbeiten Sie Ihre Konfigurationsdatei normalerweise befindet sich in ‚~/.ssh/config‘, und sich am Anfang der Datei, fügen Sie die folgenden Zeilen

Host * 
    User     your_login_user 
    StrictHostKeyChecking no 
    IdentityFile   ~/my_path/id_rsa.pub 

Benutzer auf your_login_user sagt, dass diese Einstellungen
StrictHostKeyChecking auf no your_login_user gehört wird die Aufforderung
Identity ist Pfad zu RSA-Schlüssel

Dies funktioniert für mich und meine Skripte, viel Glück für Sie vermeiden .

Answer 9

Diese Warnung wird aufgrund der Sicherheitsfunktionen ausgegeben. Deaktivieren Sie diese Funktion nicht.

Es wird nur einmal angezeigt.

Wenn es immer noch nach der zweiten Verbindung erscheint, liegt das Problem wahrscheinlich in der Datei known_hosts. In diesem Fall werden Sie auch die folgende Meldung erhalten:

Failed to add the host to the list of known hosts 

Sie es beheben kann, indem Besitzer die Berechtigungen der Datei ändern, indem Sie Ihre Benutzer beschreibbar zu sein.

sudo chown -v $USER ~/.ssh/known_hosts 

Answer 10

Tun Sie dies -> chmod + w ~/.ssh/known_hosts Diese Erlaubnis bei ~/in die Datei .ssh/known_hosts fügt schreiben.Danach wird der Remote-Host zur Datei "known_hosts" hinzugefügt, wenn Sie das nächste Mal eine Verbindung herstellen.

Answer 11

Mit Bezug auf Coris Antwort, habe ich es geändert und unten Befehl verwendet, der funktioniert. Ohne exit wurde verbleibenden Befehl Anmeldung tatsächlich zu Remote-Rechner, die ich nicht in Skript Idealer

ssh -o StrictHostKeyChecking=no user@ip_of_remote_machine "exit" 

Answer 12

wollten, sollten Sie eine selbstverwaltete Zertifizierungsstelle erstellen. Beginnen Sie mit einem Schlüsselpaar zu erzeugen: ssh-keygen -f cert_signer

Dann meldet jeden öffentlichen Host-Schlüssel des Servers: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Dies erzeugt ein signierter öffentlicher Host-Schlüssel: /etc/ssh/ssh_host_rsa_key-cert.pub

In /etc/ssh/sshd_config weist die HostCertificate auf diese Datei : HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Starten Sie den Dienst sshd erneut: service sshd restart

dann auf dem SSH-Client die folgenden ~/.ssh/known_hosts hinzufügen: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

Die oben enthält:

• @cert-authority
• Die Domain *.example.com
• Der vollständige Inhalt des öffentlichen Schlüssels cert_signer.pub

Der öffentliche Schlüssel cert_signer vertraut jedem Server, dessen öffentlicher Hostschlüssel vom privaten Schlüssel cert_signer signiert wurde.

Obwohl dies eine einmalige Konfiguration auf der Clientseite erfordert, können Sie mehreren Servern vertrauen, einschließlich solchen, die noch nicht bereitgestellt wurden (solange Sie jeden Server signieren).

Weitere Einzelheiten finden Sie unter this wiki page.