Les clés SSH DSA ne fonctionnent plus pour l'authentification sans mot de passe

Après la mise à niveau vers Fedora 23, l'authentification sans mot de passe (basée sur une clé publique) ne fonctionne plus dans SSH: lorsque vous essayez de SSH vers un hôte, il vous demande mon mot de passe sur l'hôte distant. Je n'arrive pas à utiliser ma clé privée SSH. Tout fonctionnait bien avec Fedora 22.

Ma clé publique est une clé DSA ( ~/.ssh/id_dsa.pub). J'utilise OpenSSH 7.1 ( openssh-7.1p1-5.fc23.x86_64).

Comment puis-je obtenir à nouveau l'authentification sans mot de passe pour fonctionner correctement?

— DW
source

Dupe de superuser.com/questions/962918/… et (cross) unix.stackexchange.com/questions/247612/…

— dave_thompson_085

Merci, @ dave_thompson_085. Ce n'est pas une dupe de superuser.com/q/962918/93541 . Cette question demande comment l'utiliser ssh -Q. Il s'agit de savoir comment résoudre un échec de SSH. J'ai trouvé une partie du matériel sur superuser.com/q/962918/93541 et ailleurs utile pour identifier cette solution, mais la réponse y décrit comment utiliser ssh -Qet ne répond pas à cette question (par exemple, elle n'explique pas comment corriger) ce problème), donc à mon avis, ce n'est pas un dup. Celui sur Unix et Linux est très similaire; J'aimerais avoir vu celui-là plus tôt. Merci encore pour les liens!

— DW

Ack, vous avez raison. Je les ai tous deux marqués comme "OpenSSH 7.0 no DSA", ce qui dans le premier cas n'est pas assez proche. Désolé.

— dave_thompson_085

Réponses:

Ceci est le résultat de la mise à niveau vers OpenSSH 7.0. Comme le disent les notes de publication d'OpenSSH 7.0 , "La prise en charge des clés d'hôte et d'utilisateur ssh-dss est désactivée par défaut au moment de l'exécution".

La solution consiste à ajouter la ligne suivante à ~/.ssh/configsur chaque ordinateur client (chaque ordinateur sur lequel vous exécutez le client SSH):

PubkeyAcceptedKeyTypes=+ssh-dss

Si le serveur utilise OpenSSH 7.0 ou une version plus récente, vous devrez également ajouter cette ligne à /etc/ssh/sshd_configsur chaque machine serveur.

Vous pouvez également générer une clé SSH entièrement nouvelle et l'ajouter à votre fichier authorized_keys sur chaque serveur auquel vous souhaitez vous connecter. Je vous recommande d'utiliser RSA , pour éviter les problèmes de compatibilité. Je ne recommande pas ECDSA, car apparemment gnome-keyring-daemon ne récupère pas automatiquement les clés SSH de type ECDSA.

Remarque éditoriale: Pourquoi les gens d'OpenSSH ont-ils désactivé les clés DSA? Je ne sais pas. Pour autant que je sache, il n'y a rien de mal à la sécurité des clés DSA (ssh-dss). La page Web d'OpenSSH affirme que ssh-dss est faible, mais pour autant que je sache, ssh-dss 1024 bits n'est pas plus faible que RSA 1024 bits, et les clés RSA 1024 bits ne sont pas désactivées.

— DW
source

La sélection du type de clé est discutée sur la sécurité pendant un certain temps. La sécurité des clés DSA est discutable dès le début et moins sécurisée si vous ne disposez pas d'un bon générateur aléatoire (dont vous ne pouvez pas vous assurer). Et comme il existe maintenant d'autres types de clés possibles à utiliser, il n'y a aucune raison de conserver ceux qui sont douteux.

— Jakuje

@Jakuje, oui, la sélection du type de clé est discutée ici et ici sur la sécurité de l'information . J'ai lu tout cela avant d'écrire ma remarque éditoriale, et je ne comprends toujours pas pourquoi les clés DSA ont été désactivées: elles ne sont pas plus faibles que les clés RSA de même longueur, qui n'ont pas été désactivées. Il n'y a rien dans ces threads qui indique que DSA est "discutable", et comme le dit Thomas Pornin, "il n'y a aucune raison liée à la sécurité de préférer un type à un autre, en supposant des clés suffisamment grandes". (suite)

— DW

Voir ici pour une discussion plus détaillée.

— DW

Mes deux centimes

En tant que .ssh/configfichier d' édition afin de permettre que cela semble être une mauvaise idée, je suggère

Créez une nouvelle clé, en utilisant un outil récent.

Copiez ensuite la nouvelle clé publique (dans le clipbord)
Connectez-vous une dernière fois en utilisant l'ancienne clé:
```
ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
```
Ensuite , mettez à niveau @hostle authorized_keysfichier, en ajoutant votre nouvelle clé de pub et déconnectez-vous
```
cat >>.ssh/authorized_keys
```
paste, puis Ctrl+D
Connectez-vous avec une nouvelle clé en utilisant la syntaxe par défaut:
```
ssh user@host
```
1. Ensuite , mettez à niveau @hostle authorized_keysfichier, en supprimant votre ancienne pubkey (j'utilise sed -e 1d -i .ssh/authorized_keyslorsque mon ancienne pubkey est en ligne 1de ce fichier).
2. Je suggère de mettre à niveau votre serveur ssh si vous le pouvez.
3. Connectez - Out

Testez si l'ancienne clé ne fonctionne plus.

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

Cela ne doit pas fonctionner ;-)

Vous pouvez même revérifier si tout va bien:
```
ssh user@host uptime
```

— F. Hauri
source

Ce n'est pas évident pour moi pourquoi vous pensez que l'édition ~/.ssh/confign'est pas une si bonne idée.

— DW

Parce que c'est obsolète et que l'auteur de ssh recommande de ne pas l'utiliser. Voir openssh.com/legacy.html

— F. Hauri

Oh je comprends. Il semble que votre préoccupation ne soit pas avec l'idée de l'édition en ~/.ssh/configsoi, mais plutôt avec l'idée d'autoriser le DSA. Merci d'avoir expliqué. Ça a du sens. (Je pense que j'ai déjà expliqué dans ma réponse et mes commentaires pourquoi je trouve cette recommandation déroutante, mais je n'essaierai pas d'en débattre ici.)

— DW

L'édition .configvous permet d'exécuter sshpendant longtemps et même de penser que vous utilisez un algorithme faible . En utilisant -o Pubkey...à la ligne de commande, vous ne pardonnerez pas qu'il y a quelque chose à mettre à niveau .

— F.Hauri