27 votes

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

Après la mise à jour vers Fedora 23, l'authentification sans mot de passe (basée sur une clé publique) ne fonctionne plus en SSH : lorsque j'essaie de me connecter en SSH à un hôte, l'hôte distant me demande mon mot de passe. 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 faire pour que l'authentification sans mot de passe fonctionne à nouveau correctement ?

44voto

Chanoch Points 350

C'est le résultat de la mise à jour vers OpenSSH 7.0. Comme le Les notes de mise à jour d'OpenSSH 7.0 précisent que , "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 machine cliente (chaque machine sur laquelle 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 vous devez ajouter cette ligne à /etc/ssh/sshd_config sur 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, comme apparemment gnome-keyring-daemon ne prend pas automatiquement en charge Clés SSH de type ECDSA.


Remarque rédactionnelle : Pourquoi les gens d'OpenSSH ont-ils désactivé les clés DSA ? Je ne sais pas. Pour autant que je puisse en juger, il n'y a aucun problème avec la sécurité des clés DSA (ssh-dss). Le site Page web d'OpenSSH prétend 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.

0voto

Brandon Belvin Points 360

Mes deux cents

En tant que montage .ssh/config afin de permettre ce qui semble être une pas si bien que ça idée, je suggère

  1. Créez une nouvelle clé, en utilisant l'outil récent.

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

  2. Journal de bord une dernière fois en utilisant l'ancienne clé :

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

    Puis mettre à niveau @host 's authorized_keys en ajoutant votre nouvelle clé publique et se déconnecter

    cat >>.ssh/authorized_keys

    paste entonces Ctrl + D

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

    ssh user@host
    1. Puis mettre à niveau @host 's authorized_keys par enlever vous vieux clé publique (J'utilise sed -e 1d -i .ssh/authorized_keys quand mon ancienne pubkey est en ligne 1 de ce dossier).

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

    3. déconnexion

  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 revérifier si tout va bien :

    ssh user@host uptime

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X