Forum Linux.général SSH me demande toujours mon mot de passe.

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
1
4
mai
2017

Bonjour,
après avoir tout bien fait pour pouvoir me connecter au travers d'SSH sans mot de passe, authentification par clefs, je dois toujours fournir ce mot de passe, et ça m'énerve.

Ce que j'ai fait (Fedora 25 côté client et serveur), en suivant SSH : Authentification par clé :

  • sur le client : génération de la paire de clefs
ssh-keygen -t dsa

les deux fichiers id_dsa et id_dsa.pub se trouvent bien dans ~/.ssh/

  • copie des clefs vers le serveur :
ssh-copy-id -i ~/.ssh/id_dsa.pub user@ip_machine
  • sur le serveur, modif. de /etc/ssh/sshd_config comme suit :
PubkeyAuthentication              yes
AuthorizedKeysFile                .ssh/authorized_keys
ChallengeResponseAuthentication   yes
PermitRootLogin                   no
  • sur le client j'ai créé le fichier ~/.ssh/config suivant :
Host serveur
 HostName 192.168.1.46
 User popol
 Port 22
 IdentityFile ~/.ssh/.id_dsa

popol étant l'utilisateur côté serveur.

  • et enfin côté client, j'ai modifié les droits des fichiers de ~/.ssh/ :
ls -alF .ssh
total 24
drwx------.  2 manu manu 4096  4 mai   20:49 ./
drwx------. 82 manu manu 4096  4 mai   20:42 ../
-rw-------.  1 manu manu   86  4 mai   20:42 config
-rw-------.  1 manu manu  668 28 avril 22:56 id_dsa
-rw-------.  1 manu manu  602 28 avril 22:56 id_dsa.pub
-rw-r--r--.  1 manu manu  174  4 mai   20:49 known_hosts

J'ai bien tout bien fait, non ? Et ben ça marche pô ! SSH me demande encore le mot de passe du compte.
J'ai parcouru l'interweb de long en large et je sèche. À l'aideeeeeeeee …

  • # vérifications supplémentaires

    Posté par  . Évalué à 2. Dernière modification le 04 mai 2017 à 21:08.

    As-tu redémarré le service sshd après modification de la configuration ?

    Pour pousser l'analyse plus loin :
    côté client : ssh -vvv pour avoir les traces de communications avec le serveur
    côté serveur regarde les logs du service SSHD en lançant son exécution avec les paramètres pour qu'il soit plus verbeux.
    D'un côté ou de l'autre la clef SSH publique ou privée n'est pas vu : côté client c'est la clef publique et côté serveur la clef privée.

    Je n'utilise jamais cette commande "ssh-copy-id -i ~/.ssh/id_dsa.pub user@ip_machine" mais l'objectif est d'avoir la clef privée stocké sur le serveur. Vérifie qu'elle y soit car en paramètre tu précises la clef publique.

    • [^] # Re: vérifications supplémentaires

      Posté par  (site web personnel) . Évalué à 1.

      Merci.
      Oui le service à été redémarré.
      Je n'ai pas regardé les logs côté serveur, mais pour ssh -vvv regarde ma réponse plus bas.
      En fait j'ai utilisé ssh-keygen user@machine, sans préciser le nom du fichier. Et oui la clef est bien sur le serveur :<

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

  • # j'ai eu le cas aujourd'hui avec une redhat 6.4

    Posté par  . Évalué à 3.

    en fait il fallait changer les droits du dossier /root
    il etait en 770 (drwxrwx---)
    ca a marché quand j'ai mis 700 (drwx------)

    • [^] # Re: j'ai eu le cas aujourd'hui avec une redhat 6.4

      Posté par  (site web personnel) . Évalué à 1.

      J'ai oublié de le dire, mais j'ai aussi fait ça (chmod 700 sur ~/.ssh/ et chmod 600 sur les fichiers).
      Merci.

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

      • [^] # Re: j'ai eu le cas aujourd'hui avec une redhat 6.4

        Posté par  . Évalué à 2.

        J'ai oublié de le dire, mais j'ai aussi fait ça (chmod 700 sur ~/.ssh/ et chmod 600 sur les fichiers).

        et moi je te parles de /root
        pas de .ssh

        • [^] # Re: j'ai eu le cas aujourd'hui avec une redhat 6.4

          Posté par  (site web personnel) . Évalué à 1.

          Désolé d'insister, mais je ne pige pas trop. Côté serveur j'ai :

          ls -alF /
total 92
dr-xr-xr-x.  23 root root  4096 30 avril 19:24 ./
dr-xr-xr-x.  23 root root  4096 30 avril 19:24 ../
lrwxrwxrwx.   1 root root     7  3 févr.  2016 bin -> usr/bin/
dr-xr-xr-x.   6 root root  4096 30 avril 19:38 boot/
drwxr-xr-x.   2 root root  4096 21 mars   2016 .cache/
drwxr-xr-x.   2 root root  4096 21 mars   2016 .config/
drwxr-xr-x.  20 root root  4220 30 avril 20:29 dev/
drwxrwxrwx.   1 root root  4096 10 juil.  2016 donnees1/
drwxrwxrwx.   1 root root  4096 10 juil.  2016 donnees2/
drwxr-xr-x. 137 root root 12288  3 mai   03:13 etc/
drwxr-xr-x.   5 root root  4096  3 févr.  2016 home/
lrwxrwxrwx.   1 root root     7  3 févr.  2016 lib -> usr/lib/
lrwxrwxrwx.   1 root root     9  3 févr.  2016 lib64 -> usr/lib64/
drwxr-xr-x.   3 root root  4096 21 mars   2016 .local/
drwx------.   2 root root 16384 29 oct.   2015 lost+found/
drwxr-xr-x.   2 root root  4096  3 févr.  2016 media/
drwxr-xr-x.   2 root root  4096  3 févr.  2016 mnt/
drwxr-xr-x.   2 root root  4096  3 févr.  2016 opt/
dr-xr-xr-x. 278 root root     0 30 avril 22:29 proc/
dr-xr-x---.   8 root root  4096  4 mai   20:45 root/
drwxr-xr-x.  43 root root  1240  4 mai   23:04 run/
lrwxrwxrwx.   1 root root     8  3 févr.  2016 sbin -> usr/sbin/
drwxr-xr-x.   2 root root  4096  3 févr.  2016 srv/
dr-xr-xr-x.  13 root root     0 30 avril 20:29 sys/
drwxrwxrwt.  28 root root   620  4 mai   23:19 tmp/
drwxr-xr-x.  12 root root  4096 30 avril 19:24 usr/
drwxr-xr-x.  21 root root  4096 30 avril 19:24 var/

          Donc dr-xr-x---. root/, c'est lui que je dois modifié ? Ça ne me semble pas très logique, c'est pour ça.

          « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

  • # Seveur

    Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 04 mai 2017 à 21:53.

    Sur le serveur, la clé doit être dans ~/.ssh/authorized_keys et ce fichier doit être en 0600. Le dossier .ssh, comme mentionné plus haut, doit être en 0700.

    Ensuite, si ça ne passe toujours pas, il y a possibilité de lancer sur le client avec du debug:

    ssh -vvv user@serveur

    Il faudra ensuite analyser la sortie.

    La gelée de coings est une chose à ne pas avaler de travers.

  • # authorized_keys

    Posté par  . Évalué à 3.

    Sur le serveur, tu doit créer le fichier ~/.ssh/authorized_keys. Ce fichier devra
    contenir chaque clé publique que tu veux autoriser à se connecter à ton serveur.

    Dans ton case, copie le contenu de ~/.ssh/id_dsa.pub de ton client, et met le
    dans ~/.ssh/authorized_keys de ton serveur.

    Comme dis plus haut, ~/.ssh/ doit être 0700 et ~/.ssh/authorized_keys doit
    être 0600.

    Hop,
    Moi.

  • # Pour répondre à tous (mais pas à moi)

    Posté par  (site web personnel) . Évalué à 1.

    Les droits sur le dossier .ssh étaient déjà fixés à 700, et sur les fichiers 600.
    J'ai lancé SSH en mode verbeux (ssh -vvv) et j'ai repéré deux choses :

    debug1: Skipping ssh-dss key /home/moi/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes

    et surtout :

    
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
…

    mmh …

    « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

    • [^] # Re: Pour répondre à tous (mais pas à moi)

      Posté par  . Évalué à 3. Dernière modification le 05 mai 2017 à 00:03.

      Est-ce que ça fait pareil avec une clé RSA ?

      Skipping ssh-dss key /home/moi/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes

      Sinon il doit falloir ajouter DSA aux types de clé acceptés. C’est peut-être dans le fichier sshd_config que ça se configure… là comme ça je ne sais pas.

    • [^] # Re: Pour répondre à tous (mais pas à moi)

      Posté par  . Évalué à 2.

      debug1: Skipping ssh-dss key /home/moi/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes

      ton cas semble indiqué l'usage d'une clef qui n'est pas expressement autorisé sur le serveur.

      j'ai eu le cas recemment, ou apres un upgrade du service ssh il ne prenait plus les anciennes clef (dsa, rsa)
      il avait fallu ajouter l'option PubkeyAcceptedKeyTypes avec les types dsa et rsa pour que cela fonctionne

      • [^] # Re: Pour répondre à tous (mais pas à moi)

        Posté par  (site web personnel) . Évalué à 1.

        Oups. Je ne sais pas ce que j'ai mal fait en voulant ajouter PubkeyAcceptedKeyTypes dsa mais je ne peux plus me connecter ! On verra ça plus tard, il faut que je chope un écran et un clavier.
        Merci.

        « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

        • [^] # Re: Pour répondre à tous (mais pas à moi)

          Posté par  (site web personnel) . Évalué à 1.

          Effectivement j'ai viré PubkeyAcceptedKeyTypes de sshd_config et j'ai pu me reconnecter (toujours avec mdp).

          « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

          • [^] # Re: Pour répondre à tous (mais pas à moi)

            Posté par  . Évalué à 2.

            J’ai trouvé ça : https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq=1 ça date d’il y a deux ans, sur Fedora 23…

            Je suis vraiment pas spécialiste mais, d’après le lien :

            1. La syntaxe de l’option devrait avoir cette forme : PubkeyAcceptedKeyTypes=+ssh-dss (bon ici c’est dss… mais peut-être que pour toi ce serait =+ssh-dsa) ?

            2. Je vais peut-être dire une ânerie mais il me semble qu’en plus de ta paire de clés utilisateur ton serveur SSH a une paire de clés d’hôte (/etc/ssh/ssh_host_*_key.*). Du coup si c’est par exemple une clé RSA qui est utilisée, il faut probablement que pour l’option PubkeyAcceptedKeyTypes tu indiques les deux types (RSA et DSA) ?

            • [^] # Re: Pour répondre à tous (mais pas à moi)

              Posté par  (site web personnel) . Évalué à 1.

              Merci, t'es plus pugnace que moi ;)
              PubkeyAcceptedKeyTypes=+ssh-dss est la bonne syntaxe, j'avais, comme un bourrin, mis PubkeyAcceptedKeyTypes dsa ce qui m'a empêcher ensuite de me connecter (connexion refused).

              Bon, ceci-dit il me demande toujours mon mdp. Ce n'est pas très embarrassant pour l'usage que j'en ai, mais j'aimerais bien comprendre. D'autant que ce n'est pas la première fois que je fait ça, et d'habitude ça marche en deux coup de cuiller à pot.

              Ce qui m'ennuie, c'est de ne pouvoir automatiser la connexion dans un script :<

              Merci à tous.

              « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

  • # RTFL

    Posté par  (site web personnel) . Évalué à 2.

    Read The F…g Logs

    sudo journalctl -xe

    te donneras toutes les informations pour résoudre le problème. Ça ressemble un pb de permissions sur ~popol/.. ~popol ou/et ~popol/.ssh et son contenu

    Et pour éviter de se retrouver à la porte suite à une mauvaise configuration ssh, une fois que tu as modifié la conf du serveur et relancé celui-ci, tente une //nouvelle// connexion sur le serveur pour valider les paramètres.

    my 2¢

    • [^] # Re: RTFL

      Posté par  (site web personnel) . Évalué à 5.

      Et surtout avant de le relancer :

           -t      Test mode.  Only check the validity of the configuration file and sanity of the keys.  This is useful for updating sshd reliably as configuration options may change.

      • [^] # Re: RTFL

        Posté par  (site web personnel) . Évalué à 1.

        Ta configuration peut être syntaxiquement correcte, mais tu peux quand même te retrouver à la porte suite à une clé mal installée.

        Ma méthode a le mérite de tester que la connexion reste possible avec la nouvelle configuration.

  • # Je dis peut être une connerie

    Posté par  . Évalué à 4. Dernière modification le 05 mai 2017 à 21:04.

    Tu ne te serais pas trompé dans ton fichier de config sur ton client (~/.ssh/config) :

    IdentityFile ~/.ssh/.id_dsa

    J'aurais plutôt mis 

    IdentityFile ~/.ssh/id_dsa

    • [^] # Re: Je dis peut être une connerie

      Posté par  (site web personnel) . Évalué à 4.

      Bien vu !
      En fait pour ce forum j'ai fait un copié-collé depuis le wiki de Fedora et j'avais remarqué, et corrigé de mon côté, cette coquille. Faudrait que je fasse remonter.
      Merci.

      « Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.