web-dev-qa-db-fra.com

Les clés DSH SSH 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: lors de la tentative de SSH sur un hôte, elle demande mon mot de passe sur l'hôte distant. Je ne parviens pas à utiliser ma clé privée SSH. Tout a bien fonctionné 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 faire en sorte que l'authentification sans mot de passe fonctionne à nouveau correctement?

linuxsshfedoraopenssh
25
D.W.

Ceci est le résultat de la mise à niveau vers OpenSSH 7.0. Comme l'indiquent les notes de version pour 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/config sur 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 devez également ajouter cette ligne à /etc/ssh/sshd_config sur chaque ordinateur serveur.

Vous pouvez également générer une clé SSH entièrement nouvelle et l'ajouter à votre fichier allowed_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 employés OpenSSH ont-ils désactivé les clés DSA? Je ne sais pas. Pour autant que je sache, la sécurité des clés DSA (ssh-dss) n’est pas un problème. La page Web OpenSSH affirme que ssh-dss est faible, mais à ma connaissance, ssh-dss 1024 bits n’est pas plus faible que RSA 1024 bits et 1024 bits. Les clés RSA ne sont pas désactivées.

39
D.W.

Mes deux centimes

Comme modification du fichier .ssh/config afin de permettre cela semble être une idée moins bonne , je suggère

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

    Puis copiez la nouvelle clé publique (dans le clipbord)

  2. 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 le fichier @Host's authorized_keys en ajoutant votre nouvelle clé publique et votre session.

    cat >>.ssh/authorized_keys

    paste, puis Ctrl+D

  3. Connectez-vous avec la nouvelle clé en utilisant la syntaxe par défaut:

    ssh user@Host

    1. Ensuite, mettez à niveau le fichier @Host de authorized_keys, par suppression votre ancien pubkey (J'utilise sed -e 1d -i .ssh/authorized_keys lorsque mon ancien pubkey est sur la ligne 1 de ce fichier).

    2. Je suggère de mettre à niveau votre serveur ssh si vous le pouvez.

    3. connectez - Out

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

  5. Vous pouvez même vérifier si tout va bien:

    ssh user@Host uptime
0
F. Hauri