it-swarm.com.de

ssh: Die Authentizität des Host-Hostnamens kann nicht festgestellt werden

Wenn ich zu einer Maschine ssh, bekomme ich irgendwann diese Fehlermeldung und es wird "Ja" oder "Nein" angezeigt. Dies führt zu Problemen, wenn Skripts ausgeführt werden, die automatisch auf andere Maschinen ssh übertragen.

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?

132
Senthil A Kumar

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 NULL-Datei known_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

EDIT

Wie @IanDunn feststellt, bestehen dabei Sicherheitsrisiken. Wenn die Ressource, zu der Sie eine Verbindung herstellen, von einem Angreifer gefälscht wurde, könnte der Angreifer die Herausforderung des Zielservers möglicherweise erneut an Sie weitergeben und Sie glauben, dass Sie sich mit der Remote-Ressource verbinden, während Sie tatsächlich eine Verbindung zu dieser Ressource herstellen Ihre Referenzen. Sie sollten sorgfältig überlegen, ob dies ein angemessenes Risiko ist, bevor Sie Ihren Verbindungsmechanismus ändern, um HostKeyChecking zu überspringen.

Referenz .

112
cori

Alte Frage, die eine bessere Antwort verdient.

Sie können die interaktive Aufforderung verhindern, ohne StrictHostKeyChecking zu deaktivieren (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 prüft, ob der öffentliche Schlüssel des Servers in known_hosts ist. Ist dies nicht der Fall, fordert er den öffentlichen Schlüssel vom Server an und fügt ihn known_hosts hinzu. 

Auf diese Weise sind Sie nur einmal einem Man-In-The-Middle-Angriff ausgesetzt, der möglicherweise durch Folgendes gemildert wird:

  • stellen Sie sicher, dass sich das Skript zum ersten Mal über einen sicheren Kanal verbindet
  • Überprüfen von Protokollen oder known_hosts, um Fingerabdrücke manuell zu prüfen (nur einmal durchzuführen)
65

Fügen Sie die folgenden Zeilen an den Anfang von /etc/ssh/ssh_config... ein, um die Deaktivierung zu deaktivieren (oder die Deaktivierung zu steuern).

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

Optionen:

  • Das Host-Subnetz kann * sein, um den uneingeschränkten Zugriff auf alle IPs zu ermöglichen.
  • Bearbeiten Sie /etc/ssh/ssh_config für die globale Konfiguration oder ~/.ssh/config für die 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

33
Jim Fred

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

15
richard

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

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

Der Benutzer, der auf your_login_user eingestellt ist, besagt, dass diese Einstellung zu Ihrem_Login_Benutzer gehört
Wenn StrictHostKeyChecking auf no gesetzt ist, wird die Eingabeaufforderung umgangen
IdentityFile ist der Pfad zum RSA-Schlüssel 

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

10
Carlos M G T

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 known_hosts, erfordert jedoch keine Ja/Nein-Intervention.

ssh -o BatchMode=yes -o StrictHostKeyChecking=no [email protected] "uptime"
9
Cory Ringdahl

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_hosts-Datei ..__ In diesem Fall erhalten Sie auch die folgende Meldung:

Failed to add the Host to the list of known hosts 

Sie können dies beheben, indem Sie den Eigentümer ändern, um die Berechtigungen der Datei so zu ändern, dass sie von Ihrem Benutzer beschrieben werden können.

Sudo chown -v $USER ~/.ssh/known_hosts
6
Sfisioza

Mit Bezug auf Coris Antwort habe ich sie geändert und den folgenden Befehl verwendet, der funktioniert. Ohne exit war der verbleibende Befehl tatsächlich eine Protokollierung auf einem entfernten Computer, was ich im Skript nicht wollte

ssh -o StrictHostKeyChecking=no [email protected]_of_remote_machine "exit"
4

Im Allgemeinen tritt dieses Problem auf, wenn Sie die Schlüssel sehr häufig ändern. Je nach Server kann es einige Zeit dauern, den neuen Schlüssel zu aktualisieren, den Sie generiert und in den 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 anschließend. Das Problem sollte gelöst sein. Es ist mir passiert.

2
mk..

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

Unterschreiben Sie dann den öffentlichen Host-Schlü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

Verweisen Sie in /etc/ssh/sshd_config die HostCertificate auf 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 zu ~/.ssh/known_hosts hinzu: @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 öffentliche cert_signer-Schlüssel vertraut jedem Server, dessen öffentlicher Host-Schlüssel vom cert_signer-privaten Schlüssel signiert ist. 

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

Für weitere Details siehe diese Wiki-Seite

1
Robert Chen

Tun Sie dies -> Chmod + w ~/.ssh/known_hosts Dadurch werden der Datei ~/.ssh/known_hosts Schreibrechte hinzugefügt. Danach wird der entfernte Host bei der nächsten Verbindung mit der Datei known_hosts hinzugefügt.

1
Akshayraj Kore

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

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no
0
Kevin Nguyen

Führen Sie dies auf dem Host-Server aus 

chmod -R 700 ~/.ssh
0
Robert A