ssh: Die Authentizität der Host ‚Hostname‘ kann nicht hergestellt werden

StackOverflow https://stackoverflow.com/questions/3663895

Frage

Wenn ich auf eine Maschine ssh, bekomme ich irgendwann diesen Fehler Warnung und fordert es „ja“ oder „nein“ zu sagen. Diese Ursache einige Schwierigkeiten, wenn sie von Skripten, die automatisch ssh auf andere Maschinen ausgeführt 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, automatisch zu sagen „Ja“ oder das ignorieren?

War es hilfreich?

Lösung

Abhängig von Ihrem SSH-Client, können Sie die StrictHostKeyChecking Option nicht auf der Kommandozeile gesetzt und / oder den Schlüssel in eine Datei null known_hosts senden. Sie können auch diese Optionen in der Konfigurationsdatei, entweder für alle Hosts oder für eine bestimmte Gruppe von IP-Adressen oder Hostnamen gesetzt. 

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

Bearbeiten

Wie @IanDunn Notizen gibt es Sicherheitsrisiken dies zu tun. Wenn die Ressource, die Ihnen von einem Angreifer manipuliert wurde sich verbinden, könnten sie wiederholen möglicherweise die Herausforderung zurück des Zielservers zu Ihnen, Sie zu denken, täuscht, dass Sie die Remote-Ressource sich verbinden, während sie in der Tat auf diese Ressource verbinden mit Ihre Zugangsdaten. Sie sollten sorgfältig prüfen, ob das ein angemessenes Risiko zu übernehmen, bevor Sie Ihren Verbindungsmechanismus zu verändern HostKeyChecking zu überspringen.

Referenz .

Andere Tipps

Alte Frage, die eine bessere Antwort verdient.

Sie können interaktive verhindern Aufforderung ohne StrictHostKeyChecking zu deaktivieren (die 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 wird überprüft, wenn die öffentlichen Schlüssel des Servers in known_hosts ist. Wenn nicht, fordert er die öffentlichen Schlüssel vom Server und fügt sie known_hosts.

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

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

zu 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 kann * sein uneingeschränkt zu ermöglichen, Zugriff auf alle IP-Adressen.
  • Bearbeiten /etc/ssh/ssh_config für die globale Konfiguration oder ~/.ssh/config für anwenderspezifische 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, ~/.ssh/known_hosts beschreibbar ist. Dass regelte es für mich.

Der beste Weg, um dies zu realisieren ist ‚Batchmode‘ auf ‚StrictHostKeyChecking‘ zusätzlich zu verwenden. Auf diese Weise Ihr Skript einen neuen Host-Namen akzeptieren und an die known_hosts-Datei schreibt, wird aber nicht ja / nein Intervention erfordern. 

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

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

Benutzersatz your_login_user sagt, dass diese Einstellungen zu your_login_user
gehört StrictHostKeyChecking Satz nicht die Aufforderung
vermeiden Identity ist Pfad zu RSA-Schlüssel

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

Diese Warnung durch die Sicherheitsmerkmale ausgegeben wird, diese Funktion nicht deaktivieren.

Es ist nur einmal angezeigt.

Wenn es scheint, noch nach dem zweiten Verbindung, ist das Problem wahrscheinlich schriftlich an die known_hosts Datei. In diesem Fall werden Sie auch die folgende Meldung erhalten: 

Failed to add the host to the list of known hosts

Sie können das Problem beheben, indem Besitzer der Änderung der Rechte der Datei ändern, indem Sie Ihre Benutzer beschreibbar zu sein. 

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

Mit Bezug auf Cori Antwort, modifizierte ich es und unter Befehl verwendet, die funktionieren. Ohne exit wurde verbleibenden Befehl Anmeldung tatsächlich zu Remote-Rechner, die ich nicht in Skript wollte 

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

Tun Sie dies -> chmod +w ~/.ssh/known_hosts. Dies fügt Schreibzugriff auf die Datei auf ~/.ssh/known_hosts. Danach wird die Remote-Host in die known_hosts Datei hinzugefügt werden, wenn Sie es das nächste Mal verbinden.

Generell dieses Problem tritt auf, wenn Sie die Schlüssel zu modifizieren sind sehr oftenly. Basierend auf dem Server kann es einige Zeit dauern, um den neuen Schlüssel zu aktualisieren, dass Sie generiert haben und in dem Server eingefügt. So, nachdem Sie den Schlüssel zu erzeugen und in dem Server einfügen, warten Sie auf 3 bis 4 Stunden und dann versuchen. Das Problem soll gelöst werden. Es geschah mit mir.

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

unterzeichnen dann 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 einen signierten öffentlichen Host-Schlüssel: /etc/ssh/ssh_host_rsa_key-cert.pub

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

Starten Sie den sshd Service: service sshd restart

Dann auf dem SSH-Client, fügen Sie folgendes zu ~/.ssh/known_hosts: @cert-authority *.example.com ssh-rsa AAAAB3Nz...cYwy+1Y2u/

Die oben gezeigt enthält:

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

Die cert_signer öffentlichen Schlüssel vertrauen jeden Server, dessen öffentlichen Host-Schlüssel wird vom cert_signer privaten Schlüssel signiert.

Obwohl dies erfordert eine einmalige Konfiguration auf der Client-Seite können Sie mehr Server vertrauen, auch solche, die bisher noch nicht (so lange, wie Sie jeden Server anmelden, das ist) bereitgestellt haben.

Weitere Informationen finden Sie unter diese Wiki-Seite .

Fügen Sie diese an Ihre / etc / ssh / ssh_config 

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Führen Sie diese in Host-Server es Vorahnung Ausgabe 

chmod -R 700 ~/.ssh

hatte ich die gleichen Fehler und wollte die Aufmerksamkeit auf die Tatsache lenken, dass - wie es mir gerade passiert ist -. Sie können nur falsch Privilegien
Sie haben Ihr .ssh Verzeichnis entweder als regelmäßige oder root Benutzer einrichten und so müssen Sie die richtigen Benutzer sein. Wenn dieser Fehler erschien, war ich root aber ich konfigurierte .ssh als normaler Benutzer. Verlassen root es behoben.

löse ich das Problem, das unten geschrieben Fehler gibt:
Fehler:
Die Echtheit der Host ‚XXX.XXX.XXX‘ kann nicht hergestellt werden.
RSA Schlüssel lautet 09: 6c: ef: cd: 55: c4: 4f: ss: 5a: 88: 46: 0a: a9: 27: 83:. 89

Lösung:
1. Jedes openSSH Tool installieren.
2. Fahrbefehl ssh
3. es wird fragen für Sie u diesen Host wie hinzufügen. JA akzeptieren.
4. Dieser Rechner wird in der bekannten Host-Liste hinzufügen.
5. Nun können Sie mit diesem Host verbinden.

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

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top