it-swarm.com.de

SSH-DSA-Schlüssel funktionieren nicht mehr für die kennwortlose Authentifizierung

Nach dem Upgrade auf Fedora 23 funktioniert die kennwortlose (auf öffentlichen Schlüsseln basierende) Authentifizierung in SSH nicht mehr: Wenn Sie versuchen, eine SSH-Verbindung zu einem Host herzustellen, werden Sie auf dem Remote-Host zur Eingabe meines Kennworts aufgefordert. Ich kann meinen privaten SSH-Schlüssel nicht verwenden. Alles hat gut funktioniert mit Fedora 22.

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 sicherstellen, dass die kennwortlose Authentifizierung wieder ordnungsgemäß funktioniert?

25
D.W.

Dies ist das Ergebnis eines Upgrades auf OpenSSH 7.0. In den Versionshinweisen für OpenSSH 7.0 heißt es , dass die Unterstützung für ssh-dss-Host- und -Benutzerschlüssel zur Laufzeit standardmäßig deaktiviert ist.

Die Lösung besteht darin, ~/.ssh/config auf jedem Client-Computer (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 höher verwendet, müssen Sie diese Zeile auch zu /etc/ssh/sshd_config auf jedem Servercomputer hinzufügen.

Alternativ können Sie einen völlig neuen SSH-Schlüssel generieren und ihn auf jedem Server, bei dem Sie sich jemals anmelden möchten, zu Ihrer authorized_keys-Datei hinzufügen. Ich empfehle die Verwendung von RSA , um Kompatibilitätsprobleme zu vermeiden. Ich empfehle ECDSA nicht, da anscheinend der Gnome-Keyring-Daemon SSH-Schlüssel vom Typ ECDSA nicht automatisch aufnimmt .


Anmerkung der Redaktion: Warum haben die OpenSSH-Leute DSA-Schlüssel deaktiviert? Ich weiß es nicht. An der Sicherheit der DSA-Schlüssel (ssh-dss) ist meines Erachtens nichts auszusetzen. Die OpenSSH-Webseite behauptet, dass ssh-dss schwach ist, aber meines Wissens ist 1024-Bit-ssh-dss nicht schwächer als 1024 -bit RSA- und 1024-bit RSA-Schlüssel sind nicht deaktiviert.

39
D.W.

Meine zwei Cent

Da das Editieren von .ssh/config-Dateien, um dies zu ermöglichen, eine nicht so gute Idee zu sein scheint, schlage ich vor

  1. Erstellen Sie mit dem zuletzt verwendeten Tool einen neuen Schlüssel.

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

  2. Protokolliere ein letztes Mal mit dem alten Schlüssel:

    ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss [email protected]
    

    Aktualisieren Sie dann die @Host-Datei von authorized_keys, indem Sie Ihren neuen Pubkey hinzufügen und sich abmelden

    cat >>.ssh/authorized_keys
    

    paste, dann Ctrl+D

  3. Mit neuem Schlüssel unter Verwendung der Standardsyntax protokollieren:

    ssh [email protected]
    
    1. Aktualisieren Sie dann die @Host-Datei von authorized_keys durch Entfernen Sie alt Pubkey (Ich verwende sed -e 1d -i .ssh/authorized_keys, wenn mein alter Pubkey in der Zeile 1 dieser Datei steht).

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

    3. ausloggen
  4. Testen Sie, ob der alte Schlüssel nicht mehr funktioniert.

    ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss [email protected]
    ...
    Permission denied...
    

    Das muss nicht klappen ;-)

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

    ssh [email protected] uptime
    
0
F. Hauri