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

Wenn ich zu einer Maschine ssh, erhalte ich manchmal diese Fehlerwarnung und es wird aufgefordert, "Ja" oder "Nein" zu sagen. Dies führt zu Problemen beim Ausführen von Skripten, die automatisch auf andere Computer übertragen werden.

Warnmeldung:

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, automatisch "Ja" zu sagen oder dies zu ignorieren?

Abhängig von Ihrem SSH-Client können Sie die Option StrictHostKeyChecking in der Befehlszeile auf no setzen und / oder den Schlüssel an eine Datei null not_hosts 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

BEARBEITEN

Wie @IanDunn feststellt, birgt dies Sicherheitsrisiken. Wenn die Ressource, zu der Sie eine Verbindung herstellen, von einem Angreifer gefälscht wurde, kann dieser möglicherweise die Herausforderung des Zielservers an Sie zurückspielen und Sie zu der Annahme verleiten, dass Sie eine Verbindung zur Remote-Ressource herstellen, während er tatsächlich eine Verbindung zu dieser Ressource herstellt Ihre Anmeldeinformationen. Sie sollten sorgfältig prüfen, ob dies ein angemessenes Risiko darstellt, bevor Sie Ihren Verbindungsmechanismus so ändern, dass HostKeyChecking übersprungen wird.

Referenz .

Alte Frage, die eine bessere Antwort verdient.

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

Integrieren Sie die folgende Logik in Ihr Skript:

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

Es wird geprüft, ob der öffentliche Schlüssel des Servers vorhanden ist known_hosts. Wenn nicht, fordert es einen öffentlichen Schlüssel vom Server an und fügt ihn hinzu known_hosts.

Auf diese Weise sind Sie nur einmal einem Man-In-The-Middle-Angriff ausgesetzt, der durch Folgendes gemildert werden kann:

• Stellen Sie sicher, dass das Skript beim ersten Mal eine Verbindung über einen sicheren Kanal herstellt
• Überprüfen von Protokollen oder bekannten Hosts, um Fingerabdrücke manuell zu überprüfen (nur einmal durchzuführen)

Fügen Sie zum Deaktivieren (oder Steuern der Deaktivierung) die folgenden Zeilen am Anfang von /etc/ssh/ssh_config...

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

Optionen:

• Das Host-Subnetz kann *uneingeschränkten Zugriff auf alle IPs ermöglichen.
• Bearbeiten /etc/ssh/ssh_configfür globale Konfiguration oder ~/.ssh/configfü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

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

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

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

Bearbeiten Sie Ihre Konfigurationsdatei, die sich normalerweise unter '~ / .ssh / config' befindet, und fügen Sie zu Beginn der Datei die folgenden Zeilen hinzu

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

Der Benutzer, der auf gesetzt ist, gibt an your_login_user, dass diese Einstellungen zu your_login_user gehören.
StrictHostKeyChecking, das auf no gesetzt ist, vermeidet die Eingabeaufforderung
IdentityFile ist der Pfad zum RSA-Schlüssel

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

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

Es wird nur einmal angezeigt.

Wenn es nach der zweiten Verbindung immer noch angezeigt wird, liegt das Problem wahrscheinlich beim Schreiben in die known_hostsDatei. In diesem Fall erhalten Sie auch die folgende Meldung:

Failed to add the host to the list of known hosts 

Sie können das Problem beheben, indem Sie den Eigentümer ändern und die Berechtigungen der Datei so ändern, dass sie von Ihrem Benutzer geschrieben werden können.

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

In Bezug auf Coris Antwort habe ich sie geändert und den folgenden Befehl verwendet, der funktioniert. Ohne exitwurde der verbleibende Befehl tatsächlich auf einem Remote-Computer protokolliert, was ich im Skript nicht wollte

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

Mach das -> chmod +w ~/.ssh/known_hosts. Dies fügt der Datei unter eine Schreibberechtigung hinzu ~/.ssh/known_hosts. Danach wird der Remote-Host zur known_hostsDatei hinzugefügt, wenn Sie das nächste Mal eine Verbindung herstellen.

Idealerweise sollten Sie eine selbstverwaltete Zertifizierungsstelle erstellen. Beginnen Sie mit der Generierung eines Schlüsselpaars: ssh-keygen -f cert_signer

Signieren Sie dann den öffentlichen Hostschlüssel jedes Servers: ssh-keygen -s cert_signer -I cert_signer -h -n www.example.com -V +52w /etc/ssh/ssh_host_rsa_key.pub

Dadurch wird ein signierter öffentlicher Hostschlüssel generiert: /etc/ssh/ssh_host_rsa_key-cert.pub

In /etc/ssh/sshd_configweisen die HostCertificateauf diese Datei: HostCertificate /etc/ssh/ssh_host_rsa_key-cert.pub

Starten Sie den sshd-Dienst neu: service sshd restart

Fügen Sie dann auf dem SSH-Client Folgendes hinzu ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

Das Obige enthält:

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

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

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

Weitere Informationen finden Sie auf dieser Wiki-Seite .

Im Allgemeinen tritt dieses Problem auf, wenn Sie die Schlüssel sehr häufig ändern. Abhängig vom 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 dem Einfügen in den Server 3 bis 4 Stunden und versuchen Sie es dann. Das Problem sollte gelöst sein. Es ist mit mir passiert.

Fügen Sie diese Ihrer / etc / ssh / ssh_config hinzu

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Führen Sie dies auf dem Host-Server aus

chmod -R 700 ~/.ssh

Ich hatte den gleichen Fehler und wollte darauf aufmerksam machen, dass Sie - wie mir gerade passiert ist - möglicherweise nur falsche Berechtigungen haben.
Sie haben Ihr .sshVerzeichnis entweder als regulär oder als rootBenutzer eingerichtet und müssen daher der richtige Benutzer sein. Als dieser Fehler auftrat, war ich rootaber .sshals normaler Benutzer konfiguriert . Beenden rootbehoben.

Ich löse das Problem, das unten schriftlichen Fehler gibt:
Fehler:
Die Authentizität des Hosts 'XXX.XXX.XXX' kann nicht festgestellt werden.
Der Fingerabdruck des RSA-Schlüssels lautet 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83: 89.

Lösung:
1. Installieren Sie ein offenes SSH-Tool.
2. Führen Sie den Befehl ssh aus.
3. Sie werden gefragt, ob Sie diesen Host wie hinzufügen möchten. akzeptiere JA.
4. Dieser Host wird in die Liste der bekannten Hosts aufgenommen.
5. Jetzt können Sie eine Verbindung mit diesem Host herstellen.

Diese Lösung funktioniert jetzt ......