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 benutze OpenSSH 7.1 ( openssh-7.1p1-5.fc23.x86_64).

Wie kann ich sicherstellen, dass die kennwortlose Authentifizierung wieder ordnungsgemäß funktioniert?

— DW
quelle

Dupe von superuser.com/questions/962918/… und (cross) unix.stackexchange.com/questions/247612/…

— dave_thompson_085

Danke, @ dave_thompson_085. Dies ist kein Narr superuser.com/q/962918/93541 . Diese Frage fragt, wie man es benutzt ssh -Q. Hier wird gefragt, wie ein SSH-Fehler behoben werden kann. Ich fand einige der Materialien unter superuser.com/q/962918/93541 und an anderer Stelle hilfreich bei der Identifizierung dieser Lösung, aber die Antwort dort beschreibt, wie ssh -Qdiese Frage zu verwenden ist, und beantwortet sie nicht (z. B. erklärt sie nicht, wie sie zu beheben ist Dieses Problem), also meiner Meinung nach ist es kein Trottel. Das unter Unix und Linux ist sehr ähnlich. Ich wünschte, ich hätte das früher gesehen. Nochmals vielen Dank für die Links!

— DW

Ack, du hast recht. Ich ließ sie beide als "OpenSSH 7.0 no DSA" bookmarken, was im ersteren Fall nicht nah genug ist. Es tut uns leid.

— Dave_thompson_085

Antworten:

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

Die Lösung besteht darin, ~/.ssh/configauf 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 neuer verwenden, werden Sie auch brauchen Sie diese Zeile hinzufügen /etc/ssh/sshd_configauf jedem Server - Maschine.

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 offenbar 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.

— DW
quelle

Die Auswahl des Schlüsseltyps wird einige Zeit unter Sicherheit erläutert . Die Sicherheit von DSA-Schlüsseln ist von Anfang an fragwürdig und weniger sicher, wenn Sie keinen guten Zufallsgenerator haben (was Sie nicht sicher können). Und da es jetzt andere mögliche Schlüsseltypen gibt, gibt es keinen Grund, die fragwürdigen zu behalten.

— Jakuje

@ Jakuje, ja, die Auswahl des Schlüsseltyps wird hier und hier unter Informationssicherheit behandelt . Ich habe das alles gelesen, bevor ich meine redaktionelle Bemerkung schreibe, und ich bin immer noch verwundert, warum DSA-Schlüssel deaktiviert wurden: Sie sind nicht schwächer als RSA-Schlüssel gleicher Länge, die nicht deaktiviert wurden. In keinem dieser Threads gibt es Hinweise darauf, dass DSA "fragwürdig" ist, und wie Thomas Pornin sagt, "gibt es keinen sicherheitsrelevanten Grund, einen Typ einem anderen vorzuziehen, vorausgesetzt, er ist groß genug". (Forts.)

— DW

Sehen Sie hier für eine ausführlichere Diskussion.

— DW

Meine zwei Cent

Als Bearbeitungsdatei .ssh/config, um dies zu ermöglichen, scheine ich eine nicht so gute Idee zu sein

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

Kopieren Sie dann den neuen öffentlichen Schlüssel (in die Zwischenablage)
Melden Sie sich ein letztes Mal mit dem alten Schlüssel an:
```
ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
```
Aktualisieren Sie anschließend @hostdie authorized_keysDatei, indem Sie Ihren neuen Pubkey hinzufügen und sich abmelden
```
cat >>.ssh/authorized_keys
```
paste, dann Ctrl+D
Mit neuem Schlüssel unter Verwendung der Standardsyntax protokollieren:
```
ssh user@host
```
1. Aktualisieren Sie dann @hostdie authorized_keysDatei, indem Sie Ihren alten Pubkey entfernen (ich verwende, sed -e 1d -i .ssh/authorized_keyswenn mein alter Pubkey in der Zeile 1dieser Datei steht).
2. Ich schlage vor, Sie SSH-Server zu aktualisieren, wenn Sie können.
3. Ausloggen

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

ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
...
Permission denied...

Das muss nicht klappen ;-)

Sie können sogar noch einmal überprüfen, ob alles in Ordnung ist:
```
ssh user@host uptime
```

— F. Hauri
quelle

Mir ist nicht klar, warum Sie diese Bearbeitung ~/.ssh/confignicht für eine so gute Idee halten.

— DW

Weil dies veraltet ist und ssh author nicht empfehlen sollte, es nicht zu verwenden. Siehe openssh.com/legacy.html

— F. Hauri

Oh, ich verstehe. Es hört sich so an, als ob Sie sich nicht mit der Idee des Editierens ~/.ssh/configan sich befassen , sondern mit der Idee, DSA zuzulassen. Danke fürs Erklären. Das macht Sinn. (Ich glaube, ich habe bereits in meiner Antwort und meinen Kommentaren angesprochen, warum ich diese Empfehlung für rätselhaft halte , aber ich werde nicht versuchen, das hier zu diskutieren.)

— DW

Das Bearbeiten .configmacht es Ihnen möglich, sshfür eine lange Zeit und sogar im Nebel auszuführen, dass Sie schwache Algorithmen verwenden. Wenn Sie die -o Pubkey...Befehlszeile verwenden, werden Sie nicht verzeihen, dass es etwas zu aktualisieren gibt .

— F. Hauri