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

153

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?

Senthil A Kumar
quelle
27
Ich würde davon abraten. Sie müssen herausfinden, warum Sie diese Fehler erhalten, andernfalls öffnen Sie sich einem Mann im mittleren Angriff, vor dem Sie diese Fehler schützen möchten.
Peter Bagnall
3
Dies kann durch einen Serverwechsel mit diesem SSH-Schlüssel verursacht werden, oder durch jemanden, der zwischen Ihnen und dem Server sitzt und alles abhört, was Sie senden / empfangen.
Derekdreery
Was könnte der Grund für diesen Fehler sein?
AiU
Ich bin mit Peters Argument nicht einverstanden. In einer großen Organisation ist es unrealistisch, jemanden dazu zu bringen, solche Probleme zu beheben, wenn Sie nur versuchen, Ihre Arbeit zu erledigen.
Sridhar Sarnobat
Viele große Organisationen sind genau das Gegenteil von dem, was @SridharSarnobat vorschlägt. Sie müssen sicherstellen, dass die richtigen Leute diese Art von Problemen lösen, und der Versuch, sie zu umgehen, macht die Sache nur noch schlimmer.
James Moore

Antworten:

135

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 .

cori
quelle
40
Ich denke, es ist unverantwortlich, dies ohne Vorwarnung über die Auswirkungen auf die Sicherheit zu empfehlen. superuser.com/a/421084/121091 ist eine bessere Antwort IMO.
Ian Dunn
5
@IanDunn Ich würde Ihnen in einer allgemeinen SSH-Client-Situation zustimmen, aber da das OP eindeutig angibt, dass er beim Ausführen von Skripten auf dieses Problem stößt, bricht die Alternative das Skript jedes Mal, wenn sich der Hostschlüssel ändert (und es gibt eine Reihe von Gründen dafür das könnte der Fall sein), den die Antwort, auf die Sie sich bezogen haben, nicht löst. Das heißt, es ist eine gültige Kritik, deshalb habe ich meine Antwort aktualisiert, um auf das Risiko hinzuweisen.
Cori
6
Ich kann nicht glauben, dass so viele Leute diese Antwort positiv bewertet haben und dass sie vom Fragesteller akzeptiert wird. Dieser Ansatz umgeht die Sicherheitsüberprüfungen und verbindet sie mit dem Remote-Host. Überprüfen Sie, ob die Datei unknown_hosts im Ordner ~ / .ssh / über Schreibberechtigung verfügt. Wenn nicht, dann verwenden Sie diese Antwort stackoverflow.com/a/35045005/2809294
ARK
Solange Sie wissen, was Sie tun, ist dies die beste Lösung. Ich habe eine interne Website, mit der wir automatisch eine Verbindung herstellen, die VIELE (effektiv zufällige) IP-Adressen aktualisiert. Ich habe dies zur ~ / .ssh / config hinzugefügt und es funktioniert einfach. Wohlgemerkt, ich weiß, dass diese Seite so ist, wie ich denke, und wenn nicht, haben Bösewichte keinen Vorteil, da ich weiß, welche Daten übertragen werden.
user1683793
75

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)
Grzegorz Luczywo
quelle
4
Oder verwalten Sie einfach die Datei unknown_hosts für alle Computer als Teil Ihrer Infrastrukturkonfiguration.
Thilo
1
Beachten Sie, dass ssh-keyscan nicht mit ProxyCommand funktioniert: marc.info/?l=openssh-unix-dev&m=108446567718763&w=2
Richlv
1
es wird nicht wie erwartet funktionieren. `ssh-keygen -F $IP`sollte "`ssh-keygen -F $IP`"(in Anführungszeichen) sein, in anderen Fällen wird es nicht als Zeichenfolge interpretiert
avtomaton
Oder als Oneliner mit ssh-kegen Rückgabewert:ssh-keygen -F $IP >/dev/null || ssh-keyscan -H $IP >> ~/.ssh/known_hosts
Gohu
38

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

Jim Fred
quelle
19

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

Richard
quelle
4
Ist es sicher, dass jeder an bekannte_Hosts schreiben kann?
akaRem
2
@akaRem definitiv nicht. Normalerweise soll es nur für den Benutzer beschreibbar sein, dem dieser .sshOrdner gehört.
2rs2ts
Die Berechtigungen 0400sind optimal (bitte korrigieren Sie mich). In meinem Fall bestand das Problem jedoch lediglich darin, dass der .sshEigentümer des Ordners für meinen Benutzer geändert wurde, wodurch meine eigenen 0400-Berechtigungen ungültig wurden. sudoDurch die Änderung des Eigentums an mir wurde mein Problem behoben.
Charney Kaye
Dieser hat das Problem für mich behoben.
Sivaji
14

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 [email protected] "uptime"
Cory Ringdahl
quelle
10

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.

Carlos MGT
quelle
Danke, es hat wirklich den Tag gerettet. Aber wofür ist die letzte Zeile IdentityFile? Es scheint auch ohne zu funktionieren ..
Supersan
7

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
Sfisioza
quelle
5

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"
Chintamani Manjare
quelle
5

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.

ARCHE
quelle
4

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 .

Robert Chen
quelle
2

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.

mk ..
quelle
2

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

Host *
UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no
Kevin Nguyen
quelle
Weitere Informationen finden
Sie
0

Führen Sie dies auf dem Host-Server aus

chmod -R 700 ~/.ssh
Robert A.
quelle
Bitten Sie die Benutzer, die Berechtigungen für autorisierte Schlüssel und öffentliche Schlüssel von 644 auf 700 zu ändern? Und privater Schlüssel von 600 bis 700?
Nurettin
0

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.

Lavair
quelle
-3

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 ......

Rakesh Kumar Garg
quelle
Dies beantwortet die Frage nicht. Die ursprüngliche (sehr alte) Frage betraf die Möglichkeit, solche Eingabeaufforderungen automatisch per Skript zu bestätigen.
MasterAM
Wenn es für ihn funktioniert hat, funktioniert es vielleicht für andere. Keine Notwendigkeit, etwas herunterzustimmen, das tatsächlich nützlich ist
Mbotet
Das Ausführen von "ssh" funktioniert nicht. Es wird für die Verwendung von Optionen angezeigt: ssh [..] [..] [..] [Benutzer @] Hostname [Befehl]
P Satish Patro