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

Question

Wenn ich per ssh auf einen Rechner zugreife, erhalte ich manchmal diese Fehlerwarnung und werde aufgefordert, "ja" oder "nein" zu sagen. Dies verursacht einige Probleme, wenn von Skripten, die automatisch ssh zu anderen Maschinen laufen.

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?

Answer 1

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 mit null known_hosts senden. Sie können diese Optionen auch in Ihrer Konfigurationsdatei festlegen, entweder für alle Hosts oder für eine bestimmte Gruppe von IP-Adressen oder Hostnamen.

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

EDIT

Wie @IanDunn anmerkt, birgt diese Vorgehensweise Sicherheitsrisiken. Wenn die Ressource, zu der Sie eine Verbindung herstellen, von einem Angreifer gefälscht wurde, könnte dieser die Aufforderung des Zielservers an Sie zurückspielen und Ihnen vorgaukeln, dass Sie eine Verbindung zu der entfernten Ressource herstellen, während er sich in Wirklichkeit mit Ihren Anmeldedaten mit dieser Ressource verbindet. Sie sollten sorgfältig abwägen, ob Sie dieses Risiko eingehen wollen, bevor Sie Ihren Verbindungsmechanismus so ändern, dass HostKeyChecking übersprungen wird.

Referenz .

Answer 2

Eine alte Frage, die eine bessere Antwort verdient.

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

Bauen Sie die folgende Logik in Ihr Skript ein:

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

Er prüft, ob der öffentliche Schlüssel des Servers in known_hosts . Falls nicht, fordert es den öffentlichen Schlüssel vom Server an und fügt ihn zu known_hosts .

Auf diese Weise sind Sie nur einmal einem Man-In-The-Middle-Angriff ausgesetzt, der durch folgende Maßnahmen abgeschwächt werden kann:

• Sicherstellung, dass das Skript beim ersten Mal eine Verbindung über einen sicheren Kanal herstellt
• Untersuchung von Protokollen oder known_hosts zur manuellen Überprüfung von Fingerabdrücken (nur einmal durchzuführen)

Answer 3

Zum Deaktivieren (oder Kontrollieren der Deaktivierung) 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 * um den uneingeschränkten Zugang zu allen IPs zu ermöglichen.
• bearbeiten /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

Answer 4

Vergewissern Sie sich ~/.ssh/known_hosts beschreibbar ist. Damit ist das Problem für mich gelöst.

Answer 5

Am besten ist es, wenn Sie zusätzlich zu "StrictHostKeyChecking" den "BatchMode" verwenden. Auf diese Weise akzeptiert Ihr Skript einen neuen Hostnamen und schreibt ihn in die Datei "known_hosts", erfordert aber keine Ja/Nein-Eingabe.

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