Aller au contenu

Se connecter en SSH sans mot de passe

ssh-keygenSSH ou Secure SHell est une commande qui permet de se connecter à une machine distante, sur laquelle tourne un daemon (sshd).

L'intérêt de SSH est que la connexion entre les deux machine est sécurisé. Mais savez-vous que la connexion peut s'effectuer sans avoir à donner de mot de passe ?

Je vois deux intérêts principaux au fait de pouvoir se connecter sans mot de passe sur une machine distante :

- Si comme moi, vous administrez plusieurs machine, ça vous évite d'avoir à retenir les mots de passe. Ou pire, de mettre le même mot de passe partout.

- Pouvoir échanger des fichiers entre machines de manière automatique, un cron.daily pour des sauvegardes par exemple.

Voici comment faire :

Tout d'abord, il faut générer sur votre machine locale et pour votre utilisateur une clé publique et une clé privée. Pour ce faire il faut utiliser la commande suivante :

$ ssh-keygen
Vous pouvez répondre à toutes les questions posées en appuyant simplement sur la touche [Entrée], à moins que vous souhaitiez générer votre paire de clés avec une passphrase particulière.

Attention de ne pas écraser votre paire de clés si vous l'aviez déjà générée auparavant.

Ensuite, il faut diffuser la clé publique sur les machines distantes pour tous les utilisateurs sur les comptes desquels vous souhaitez pouvoir vous connecter.

$ ssh-copy-id <nom-utilisateur>@<machine-distante>
Saisissez le mot de passe de l'utilisateur visé, et c'est fait. Vous pourrez ensuite lancer une demande de connexion sur la machine en question et pour l'utilisateur choisi en utilisant la commande :
$ ssh <nom-utilisateur>@<machine-distante>
Aucun mot de passe ne vous sera demandé. Sachez également qu'il ne vous sera plus demandé de mot de passe pour la commande scp (Secure Copy), ce qui est très pratique pour envoyer une sauvegarde vers une autre machine.

17 thoughts on “Se connecter en SSH sans mot de passe

  1. avatarJohan

    Salut,
    Quelques petites précisions... Tu dis « Aucun mot de passe ne vous sera demandé » ; ce n'est pas tout à fait exact. Si la clé a été générée avec un mot de passe, c'est celui là qui pourra être demandé (et non plus celui de l'utilisateur distant).
    Générer une clé sans mot de passe pour un usage avec cron n'est généralement pas trop conseillé d'un point de vue sécurité. En effet, l'utilisateur qui lancera le cron aura tel quel un accès illimité à la machine distante, sur le compte distant spécifié.... Ça peut être dangereux :o)
    Dans le cas d'un cron, il est préférable je pense d'effectivement générer une clé sans mot de passe, mais de limiter les commandes qui pourront être exécutées sur le serveur distant (ça se passe dans le fichier ~/.ssh/authorized_keys) 😉
    Dans le cas de clés "standard" (ie. non cron) ; il faut absolument mettre un mot de passe sur la clé, et ce dernier vous sera demandé à chaque connection ; mais c'est là qu'intervient la commande magique "ssh-add" et le ssh agent d'une manière plus générale (notamment les GUI qui vous demanderont automatiquement le passe de votre clé à l'ouverture de la session, et qui s'en souviendront ensuite).

  2. avatarMarcet

    Johan: Salut, Quelques petites précisions… Tu dis « Aucun mot de passe ne vous sera demandé » ; ce n’est pas tout à fait exact. Si la clé a été générée avec un mot de passe, c’est celui là qui pourra être demandé (et non plus celui de l’utilisateur distant).

    Tu as raison, je ne suis pas assez explicite sur le fait que si on utilise une passphrase lors de la génération des clés, elle sera demandée lors de la connexion.

  3. avatarMarcet

    Johan: Générer une clé sans mot de passe pour un usage avec cron n’est généralement pas trop conseillé d’un point de vue sécurité. En effet, l’utilisateur qui lancera le cron aura tel quel un accès illimité à la machine distante, sur le compte distant spécifié…. Ça peut être dangereux :o ) Dans le cas d’un cron, il est préférable je pense d’effectivement générer une clé sans mot de passe, mais de limiter les commandes qui pourront être exécutées sur le serveur distant (ça se passe dans le fichier ~/.ssh/authorized_keys) ;-)

    Je vais regarder cet aspect des choses de plus près. Ça pourra faire l'objet d'un nouvel article 😉

  4. avatarMarcet

    Johan: Dans le cas de clés « standard » (ie. non cron) ; il faut absolument mettre un mot de passe sur la clé, et ce dernier vous sera demandé à chaque connection ; mais c’est là qu’intervient la commande magique « ssh-add » et le ssh agent d’une manière plus générale (notamment les GUI qui vous demanderont automatiquement le passe de votre clé à l’ouverture de la session, et qui s’en souviendront ensuite).

    Ça ne fait pas grande différence dans ce cas, non ?

  5. avatarJohan

    Marcet: Ça ne fait pas grande différence dans ce cas, non ?

    D'utiliser l'agent SSH ? Pour moi, si ! Il suffit d'entrer une fois le mot de passe de la clé par session, et non plus à chaque fois qu'on en a besoin (c'est fort utile lorsque l'on utilise les clés à longueur de journée) ; ne pas connaître l'agent ssh pourrait en pousser certains à utiliser des clés sans mot de passe aucun (beurk :-D).
    Côté sécurité, utiliser l'agent ssh pourrait être problématique en cas de prise de contrôle physique du poste sur lequel l'utilisateur est connecté, mais cela reste tout de même beaucoup plus sécure à mon sens.
    @ peluche
     

  6. avatarMarcet

    Johan: D’utiliser l’agent SSH ?

    Je suis bien d'accord que si une machine à accès à d'autres sans mot de passe, et que quelqu'un s'empare de la dite machine, il y a un problème de sécurité.

    Mais ça reviens à peu près au même si la clé de chaque accès ssh est stockée dans le porte-clé de la session, non ?

  7. avatarJohan

     

    Marcet: Je suis bien d’accord que si une machine à accès à d’autres sans mot de passe, et que quelqu’un s’empare de la dite machine, il y a un problème de sécurité.Mais ça reviens à peu près au même si la clé de chaque accès ssh est stockée dans le porte-clé de la session, non ?

    Si la clé ne possède pas de mot de passe, il suffit de la choper elle, la solution de l'agent ne stocke pas le passe, il faudrait donc avoir accès à l'instance de l'agent pour laquelle le passe a été saisi pour s'en servir (un poil plus compliqué que d'accéder à un simple fichier).  En plus, si je prend ta clé sans mot de passe, je peux m'en servir quand je veux ; alors que je ne pourrai pas te piquer ton l'instance de ton agent (enfin, je ne crois pas).
    Bien entendu, en termes de sécurité, la meilleure solution reste d'entrer le mot de passe de la clé à tous les coups (et que le dit mot de passe soit bien barbare, au passage :p).
    La solution de l'agent est plus ou moins entre le mot de passe à tous les coups et pas de mot de passe du tout 🙂
    Après, il peut être possible de ne pas conserver le passe pendant toute la durée de la session, ça renforcerait un peu plus la sécurité,  mais j'avoue n'avoir jamais cherché à faire ça 😉
    @ peluche

  8. avatarshnoulle

    Pour un bon équilibre entre sécurité et le coté pratique, on peut utiliser l'agent ssh pour se souvenir de la passphrase ssh ET chiffrer son disque dur ( Qui a dit luks ?).
    Même en cas de vol du PC avec les clés, l'agent ssh ne pourra pas être activé.
    Sinon, l'agent ssh c'est bien, sauf quand vous perdez votre session , et qu'il faut vous rappeler votre mot de passe (ça m'est arrivé la semaine dernière, résultat: recréation de clés, reboot des serveurs en rescue ou prise de contrôle direct pour remettre la clés).
    Autre chose concernant la sécurité, je n'utilise les clés ssh que sur des utilisateurs non root, qui peuvent passer root via un su ou un sudo. root n'a pas le droit de se connecter en ssh sur certaines de mes machines.

  9. avatarMarcet

    shnoulle: Pour un bon équilibre entre sécurité et le coté pratique, on peut utiliser l’agent ssh pour se souvenir de la passphrase ssh ET chiffrer son disque dur ( Qui a dit luks ?). Même en cas de vol du PC avec les clés, l’agent ssh ne pourra pas être activé.

    J'y avais pensé aussi. Mais dans ce cas, ça veut dire que l'on doit saisir deux mots de passe à chaque démarrage de sa machine : celui de la session et celui de la partition chiffrée, et ce, même si on ne se connecte pas en SSH lors de la session.

    shnoulle: Autre chose concernant la sécurité, je n’utilise les clés ssh que sur des utilisateurs non root, qui peuvent passer root via un su ou un sudo. root n’a pas le droit de se connecter en ssh sur certaines de mes machines.

    Ce point me semble parfaitement évident. D'ailleurs, il me semble que sous Fedora, la configuration par défaut du daemon ssh ne permet pas la connexion root.

  10. avatarjohan

    Marcet: J’y avais pensé aussi. Mais dans ce cas, ça veut dire que l’on doit saisir deux mots de passe à chaque démarrage de sa machine : celui de la session et celui de la partition chiffrée, et ce, même si on ne se connecte pas en SSH lors de la session. Ce point me semble parfaitement évident. D’ailleurs, il me semble que sous Fedora, la configuration par défaut du daemon ssh ne permet pas la connexion root.

    Malheureusement, non :/ En tous cas sous F-11, j'ai encore du éditer le sshd_config pour interdire la connexion ssh en root, et par la même occasion définir mon AllowedUsers..
    C'est vrai que je ne l'avais pas spécifié, mais pas d'accès root via ssh chez moi non plus (sur aucune de mes machines), et utilisation de sudo au besoin.
    @ peluche

  11. avatarMarcet

    @johan : Tu dois avoir installé Fedora 11 en faisant une mise à jour, car je viens de vérifier à l'instant sur une machine fraîchement installée, le PermitRootLogin est bien en commentaire par défaut dans le ssd_config.

  12. avatarMarcet

    Johan: Oui, la directive « PermitRootLogin » est commentée par défaut ; l’accès root via ssh est donc autorisé par défaut.

    Damned ! Tu veux dire que si on ne met pas "PermitRootLogin No" explicitement, c'est Yes qui est pris par défaut !!!!

    Si c'est ça c'est une énorme erreur de conception de sshd.

  13. avatarHeldwin

    En effet, les valeurs mises en commentaire sont les valeurs si pas indiquées explicitement.
    #PermitRootLogin yes
    Donc, permet le login root par défaut.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *