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?

Author: D.W., 2015-12-23

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.

 42
Author: D.W.,
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

  1. Erstellen Sie einen neuen Schlüssel, indem Sie das Werkzeug verwenden.

    Kopieren Sie dann den neuen öffentlichen Schlüssel (in den Clipbord)

  2. 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 ' s authorized_keys Datei, indem Sie Ihre neue pubkey und logout

    cat >>.ssh/authorized_keys
    

    paste, dann Strg+D

  3. Loggen Sie sich mit dem neuen Schlüssel ein, indem Sie die Standardsyntax verwenden:

    ssh user@host
    
    1. Aktualisieren Sie dann die @host - Datei von authorized_keys, indem Sie entfernen Sie alt pubkey (ich verwende sed -e 1d -i .ssh/authorized_keys, wenn mein alter Pubkey in Zeile 1 dieser Datei steht).

    2. Ich schlage vor, Sie ssh-Server zu aktualisieren, wenn Sie können.

    3. Abmelden
  4. 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 ;-)

  5. Sie können sogar noch einmal überprüfen, ob alles in Ordnung ist:

    ssh user@host uptime
    
 0
Author: F. Hauri,
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