SSH 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
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>
$ ssh <nom-utilisateur>@<machine-distante>
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).
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.
Je vais regarder cet aspect des choses de plus près. Ça pourra faire l'objet d'un nouvel article 😉
Ça ne fait pas grande différence dans ce cas, non ?
@Johan : En tout cas, merci pour toutes tes remarques très constructives.
Anéfé 😉
J'avais publié un billet sur mon blog - pour faire le miroir d'un dépôt SVN - qui utilise cette technique de limitation à une commande particuilière : http://blog.ulysses.fr/index.php/post/16/10/2008/Subversion-:-comment-creer-un-miroir-de-facon-securisee
Le plus dur, c'est encore de trouver sur quelle commande restreindre 😀
@ peluche
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
Merci. Super intéressant !
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
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.
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
@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.
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.
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.