Pourquoi se connecter par clé ?

Si vous êtes comme moi et que vous faites des scripts sous linux, notamment de backup, vous avez sans doute le problème d'exécuter des commandes à distance automatiquement.

Pour cela, le ssh est l'idéal; sécurisé, crypté, facilement configurable et utilisable.

Cependant, l'un des gros problèmes d'un script automatique, c'est qu'un mot de passe, il a un peu de mal à le taper. Alors, on peut bidouiller me direz-vous :

echo "motdepasse" ssh root@serveurIP

Pourquoi pas. Mais bon, ça oblige à mettre le mot de passe en clair, ça ne marche pas toujours selon la configuration de votre serveur ssh, et la connexion en root, c'est mal.

C'est là qu'intervient un système sympa de ssh : la connexion par clé...

Le principe : rapidement

Pour ceux qui ne sont pas trop au fait de quoi que c'est que ça, je vais rapidement rappeller le principe de se connecter à l'aide d'une clé.

En ssh, la connexion se fait en trois temps :

  • On fait une demande de connexion, le serveur renvoie une clé unique lié à sa configuration, qui va permettre de l'identifier et de chiffrer le flux (Cette demande n'est faite qu'à la première connexion)
  • On accepte (ou non) cette clé. Elle permet notamment de voir si le serveur a été changé depuis la dernière connexion (si oui, attention ! potentielle attaque d'homme dans le milieu :-) )
  • Ensuite, on rentre son mot de passe et la connexion s'établit

En fait, il y a l'identification du serveur (clé du serveur), puis notre identification (via le mot de passe)

Avec une connexion par clé, c'est quasi la même chose, sauf qu'on va nous aussi utiliser une clé pour s'identifier ! De cette façon, une fois la clé installée sur le serveur, elle ne sera plus demandée et il n'y aura plus besoin de mot de passe. (trop la classe)

Notez qu'on peut assortir la connexion  par clé d'une phrase de sécurité, à rentrer lors de la connexion et qui sécurise encore le processus. Cependant, ce n'est pas intéressant pour une connexion auto donc on ne s'en servira pas ici

Génération de la clé : les choses sérieuses commencent

Sur votre machine cliente, il va d'abord falloir générer la fameuse clé. Ou plutôt, le couple de clé, la clé publique et la clé privée. (Voir la cryptographie asymétrique)

Si ce n'est pas déjà fait, installez donc le client openssh :

$ sudo aptitude update && sudo aptitude install openssh-client

(Bien sûr, openssh serveur est installé sur votre machine distante)

Ensuite, générez la clé pour votre client :

$ ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
```<p>
    Il vous faut ensuite répondre à plusieurs questions. La valeur par défaut est correcte, il suffit donc d'appuyer sur Entrée à chaque fois. Pour la passphrase, laissez vide pour qu'elle ne soit pas utilisée (c'est ce que l'on veut pour la connexion automatique)</p>
<p>
    Une fois la clé générée, un petit resumé est affiché :</p>

Your identification has been saved in /home/utilisateur/.ssh/id_rsa. Your public key has been saved in /home/utilisateur/.ssh/id_rsa.pub. The key fingerprint is: XX:8a:XX:91:XX:ae:XX:23:XX:2e:XX:ed:XX:4e:XX:b8 utilisateur@machinecliente ```

Les deux clés (publique et privée) sont donc stockées directement dans votre dossier home, dans un dossier caché nommé .ssh/

Envoi de la clé au serveur : tuyau crypté

Le moment délicat est arrivé. Il vous faut transmettre votre clé au serveur, de préférence via un moyen crypté. (Bah oui, envoyer la clé en clair via ftp par exemple vous expose à vous la faire piquer, et donc potentiellement pirater...)

Pour ça, le meilleur moyen reste encore ssh ! Il va vous falloir une dernière fois votre mot de passe pour vous connecter au serveur. Grâce aux outils ssh, il suffit de faire :

$ ssh-copy-id -i /home/login/.ssh/id_rsa.pub login@machineserveur
Password :
```<p>
    Entrez votre mot de passe, et la clé sera directement copiée dans le dossier .ssh/authorized_keys de votre serveur. Ce dossier est dans le home de l'utilisateur du serveur (pas root hein ??)</p>

Now try logging into the machine, with "ssh 'login@machineserveur'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.

<p>
    Une fois celà fait, vous pouvez maintenant vous connecter à votre serveur sans avoir besoin d'aucun mot de passe.</p>
<p>
    Pour testez, faites donc un petit :</p>

ssh login@machineserveur

<p>
    La connexion doit s'effectuer sans mot de passe ! Vous pouvez maintenant utiliser à loisir ssh, scp, rsync, ... dans vos scripts !</p>
## Problèmes éventuels : il peut arriver que...
<p>
    Jusqu'ici, je n'ai quasiment jamais rencontré de problèmes avec l'authentification par clé.</p>
<p>
    Cependant, si ça devait vous arriver, l'une des premières choses à vérifier est que les droits Unix sur le serveur sont corrects.</p>
### ... Le serveur continue à me demander mon mot de passe !
<p>
    C'est balot. Logguez vous sur votre serveur avec le mot de passe, et vérifiez que :</p>
<ol>
    <li>
        Les droits du dossier personnel de votre utilisateur sont corrects :&nbsp;

$ ls -l /home drwxr-xr-x 5 login login 4096 3 jui. 2012 login

            Les droits doivent être identiques à l'exemple, c'est à dire en 755. Pour eventuellement corriger ça, faites&nbsp;

$ chmod 755 /home/login

        <p></p>
    </li>
    <li>
        Les droits du dossier .ssh sont corrects :

$ ls -l /home/login drwx------ 2 login login 4096 9 sept. 2011 .ssh

            De même que précedemment, si les droits ne sont pas corrects, faites&nbsp;

$ chmod 700 /home/login/.ssh

        <p></p>
    </li>
    <li>
        Les droits du fichier authorized_keys sont corrects :

$ ls -l /home/login/.ssh/authorized_keys -rw------- 2 login login 4096 9 sept. 2011 authorized_keys

            Si ce n'est pas correct, un petit :

$ chmod 600 /home/login/.ssh/authorized_keys

            devrait faire l'affaire
    </li>
</ol>
### ... Je dois utiliser un autre port que le port 22 !
<p>
    Il peut arriver que vous deviez utiliser la commande ssh-copy-id et que votre serveur utilise un port différent du port 22.</p>
<p>
    Dans ce cas, vous remarquerez que ssh-copy-id ne prend pas l'option "-p" habituellement utilisé avec ssh.</p>
<p>
    La solution est assez simple, il faut lui passer en tant qu'option ssh, de la manière suivante :&nbsp;</p>
<p></p>

$ ssh-copy-id -i /home/login/.ssh/id_dsa.pub '-pPORT login@machineserveur' ```

En fait vous pouvez même passer toutes les options propres à ssh en mettant ça entre ''. (Par exemple l'algorithme de chiffrement, ...)

Et si c'est pas ça ?

C'est jusqu'ici les seuls problèmes que j'ai eu en utilisant correctement tous les outils ssh. Posez la question dans les commentaires :)


Victor Avatar Victor est le rédacteur principal du blog.
Comments

Si vous avez des questions, si quelque chose n'est pas clair, n'hésitez pas à commenter !

  • Avatar
    Permalink

    Thibaud

    Posted on

    Article intéressant. Je salue l'iniative cher binôme. :-)

    Quelques petites remarques/questions :

    Dans un souci de sécurité accrue, tu peux ajouter la ligne "PasswordAuthentication no" dans /etc/ssh/sshd_config pour n'autoriser que l'authentification par clefs asymétriques (tu peux en profiter aussi pour mettre "PermitRootLogin no").

    Sinon, si tu te fais piquer ta clef publique lors du transfert vers ton serveur, ça n'est pas très grave puisqu'elle est… publique. ^^ Tu peux même utiliser la même sur plusieurs serveurs différents. Ce qui est important, c'est qu'elle ne soit pas été altérée lors du transfert.

    Petite question, entre ssh-copy-id et un simple scp, il y a quoi comme différence? Le "-i" c'est pour rajouter à la suite du fichier?

    Sinon pourquoi chmoder en 600 et pas en 644 le contenu de ton dossier .ssh (ce qui est le cas par défaut)? Je suis d'accord pour le faire sur id_rsa (ou id_dsa) qui est la clef privée mais sur le reste, je ne vois pas bien l'intérêt.


    • Avatar
      Permalink

      Victor

      Posted on

      Iniative intéréssée je l'avoue, j'en avais marre de toujours chercher les commandes quand j'ai cette manip à faire, alors j'ai rédigé un tuto propre selon mes critères :)

      Effectivement on peut rajouter les options dont tu parles. Cependant, ce n'est pas obligatoire pour l'accès par clé, donc je ne l'ai pas mis (l'article est déjà bien assez conséquent) Je ferai peut être un article sur la sécurisation de ssh un de ces jours !

      Du côté de ssh-copy-id, l'avantage pou moi est que cela rajoute directement à la fin du fichier authorized_keys du serveur la clé du client. En scp, il faut envoyer la clé, puis faire un cat à la main pour le recopier la clé à la fin du fichier. Moyennement pratique je trouve. Le -i (man ssh-copy-id) permet de spécifier le fichier clé à envoyer (qui est déjà par défaut ~./ssh/id_dsa.pub). Il n'est donc pas forcément nécessaire de le mettre, mais ça ne mange pas de pain :)

      Par contre avec ma commande, je n'ai chmodé que le fichier authorized_keys, pas le contenu de tout le dossier ssh/. Je l'ai fait parce que ce sont les droits par défaut du fichier sur mes serveurs, et que j'ai eu un souci de connexion un jour à cause de ça ("Uncorrect rights set on authorized_keys" dans les logs de mémoire)

Ajouter un commentaire / Add a Comment

Vous pouvez utiliser la syntaxe Markdown pour formatter votre commentaire.

You can use the Markdown syntax to format your comment.

Flux Atom pour commentaire / Comment Atom Feed

Published

Category

Système

Tags

Restez en contact