SSH-DSA-Schlüssel funktionieren nicht mehr für die kennwortlose Authentifizierung
Nach dem Upgrade auf Fedora 23 funktioniert die passwortlose (Public-Key-basierte) Authentifizierung in SSH nicht mehr: Beim Versuch, auf einem Host SSH zu verwenden, wird auf dem Remote-Host nach meinem Kennwort gefragt. Ich kann meinen privaten SSH-Schlüssel nicht verwenden. Mit Fedora 22 hat alles gut funktioniert.
Mein öffentlicher Schlüssel ist ein DSA-Schlüssel (~/.ssh/id_dsa.pub
). Ich verwende OpenSSH 7.1 (openssh-7.1p1-5.fc23.x86_64
).
Wie kann ich die passwortlose Authentifizierung wieder korrekt ausführen?
2 answers
Dies ist das Ergebnis eines Upgrades auf OpenSSH 7.0. Wie die Release Notes für OpenSSH 7.0 sagen, "Unterstützung für ssh-dss Host-und Benutzerschlüssel ist standardmäßig zur Laufzeit deaktiviert".
Die Lösung besteht darin, ~/.ssh/config
auf jedem Clientcomputer (auf jedem Computer, auf dem Sie den SSH-Client ausführen) die folgende Zeile hinzuzufügen:
PubkeyAcceptedKeyTypes=+ssh-dss
Wenn der Server OpenSSH 7.0 oder neuer verwendet, müssen Sie auch diese Zeile zu /etc/ssh/sshd_config
auf jedem Servercomputer hinzufügen.
Alternativ können Sie generieren Sie einen völlig neuen SSH-Schlüssel und fügen Sie ihn Ihrer authorized_keys-Datei auf jedem Server hinzu, auf dem Sie sich jemals anmelden möchten. Ich empfehle Ihnen, RSA zu verwenden, um Kompatibilitätsschwierigkeiten zu vermeiden. Ich empfehle ECDSA nicht, da anscheinend gnome-keyring-Daemon nicht automatisch SSH-Schlüssel vom Typ ECDSA aufnimmt.
Redaktionellen Anmerkung: Warum haben die OpenSSH Leute deaktivieren DSA-Schlüssel? Ich weiß es nicht. Soweit ich feststellen kann, ist an der Sicherheit von DSA-Schlüsseln (ssh-dss) nichts auszusetzen. Die OpenSSH - Webseite behauptet, dass ssh-dss schwach ist, aber soweit mir bekannt ist, ist 1024-Bit-SSH-dss nicht schwächer als 1024-Bit-RSA und 1024-Bit-RSA-Schlüssel sind nicht deaktiviert.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/techietown.info/template/agent.layouts/content.php on line 61
2017-03-17 13:21:41
Meine zwei Cent
Als Bearbeiten von .ssh/config
Datei, um dies zu ermöglichen, scheint eine nicht so gute Idee zu sein, schlage ich vor
-
Erstellen Sie einen neuen Schlüssel, indem Sie das Werkzeug verwenden.
Kopieren Sie dann den neuen öffentlichen Schlüssel (in den Clipbord)
-
Logge ein letztes Mal mit dem alten Schlüssel ein:
ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
Dann aktualisieren Sie
@host
' sauthorized_keys
Datei, indem Sie Ihre neue pubkey und logoutcat >>.ssh/authorized_keys
paste, dann Strg+D
-
Loggen Sie sich mit dem neuen Schlüssel ein, indem Sie die Standardsyntax verwenden:
ssh user@host
Aktualisieren Sie dann die
@host
- Datei vonauthorized_keys
, indem Sie entfernen Sie alt pubkey (ich verwendesed -e 1d -i .ssh/authorized_keys
, wenn mein alter Pubkey in Zeile1
dieser Datei steht).Ich schlage vor, Sie ssh-Server zu aktualisieren, wenn Sie können.
- Abmelden
-
Testen Sie, ob der alte Schlüssel nicht mehr funktioniert.
ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host ... Permission denied...
Dies muss nicht funktionieren ;-)
-
Sie können sogar noch einmal überprüfen, ob alles in Ordnung ist:
ssh user@host uptime
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/techietown.info/template/agent.layouts/content.php on line 61
2018-10-19 15:25:12