Vorübergehend meine `~/.ssh/known_hosts`-Datei ignorieren?

Lösung 1:

Sie können ssh -o StrictHostKeyChecking=no verwenden um die Überprüfung von known_hosts zu deaktivieren momentan. Aber davon würde ich abraten. Sie sollten wirklich prüfen, warum sich der Hostschlüssel geändert hat.

Eine weitere Möglichkeit besteht darin, Ihrem ~/.ssh/config einen bestimmten Eintrag hinzuzufügen für den betreffenden Host. Dies könnte ein gültiger Ansatz sein, wenn Sie einen bestimmten Host haben, der bei jedem Neustart neue Hostschlüssel generiert und mehrmals am Tag aus einem triftigen Grund neu gestartet wird.

Host <your problematic host>
  StrictHostKeyChecking no

Lösung 2:

Um Ihre Known-Hosts-Datei in einer POSIX-Umgebung vollständig zu ignorieren, setzen Sie den GlobalKnownHostsFile und UserKnownHostsFile Optionen zu /dev/null :

ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null [email protected]

Einstellen des StrictHostKeyChecking=no Option wird es Ihnen erlauben, sich zu verbinden, aber SSH zeigt immer noch eine Warnung :

ssh -o StrictHostKeyChecking=no [email protected]

Wie andere angemerkt haben, ist es wahrscheinlich besser, das zugrunde liegende Problem anzugehen. Sie könnten beispielsweise eine SSH-Zertifikatauthentifizierung in Betracht ziehen, um Hosts zu überprüfen.

Lösung 3:

Wenn Sie den Server neu installiert haben und sich dadurch die Identifikation geändert hat, sollten Sie einfach die angegebene Zeile 155 aus /Users/alexus/.ssh/known_hosts löschen und los geht's.

Wenn Sie zwischen verschiedenen privaten Netzwerken wechseln, sollten Sie stattdessen Hostnamen verwenden, um sich zu verbinden, da der ssh-Client auch Schlüssel in Abhängigkeit vom Hostnamen speichert. Fügen Sie Ihrem /etc/hosts so etwas hinzu :

10.52.11.171 server1
10.52.11.171 server2

und verwenden Sie dann ssh server1 bei Verbindung mit Subnetz 1 und ssh server2 bei Verbindung mit subnet2. Auf diese Weise können beide Server unterschiedliche Hostkeys haben.

Lösung 4:

-o StrictHostKeyChecking=no funktioniert nur, wenn host nicht bereits in der known_hosts-Datei vorhanden ist.

Ich denke, es ist sauberer (keine Warnungen), wenn Sie erwarten, dass sich der Host-Schlüssel möglicherweise aufgrund des VM-Klonens ändert, um das Ignorieren dieser Art von Hosts wie dieser zu erzwingen:

# Handle possible SSH key changes
host_key=$(ssh-keyscan -t rsa ${host_ip})
grep "${host_key}" ~/.ssh/known_hosts >/dev/null || {
    ssh-keygen -R ${host_ip}
    echo ${host_key} >>  ~/.ssh/known_hosts
}

# connect as normal way
ssh [email protected]${host_ip} "hostname"

Lösung 5:

Einige Leute sagen, es ist nicht richtig, Sie sollten dies nicht tun und so weiter, aber ich brauche dies auch, um einige eingebettete Geräte immer wieder zu testen. Sie müssen StrictHostKeyChecking=no deaktivieren , das ist richtig, aber setzen Sie auch die Datei bekannter Hosts auf /dev/null zurück . Hier ein Beispiel mit Autologin und ps auf dem Remote-Gerät.

sshpass -p pass ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected] 'ps ax'