Clés publiques/privés – Oubliez vos mots de passes !
Rien de plus énervant que de gérer des mots de passes ! Entre Windows, le navigateur internet, les sites mais aussi les serveurs, cela en fait un paquet à retenir, et au final on se retrouve à retaper tout le temps le même mot de passe car on en a assez de tout retenir et de les retaper. Sans compter que la connexion à un serveur par mot de passe, surtout si celui-ci n'est pas assez complexe, peut être un problème de sécurité.
Un moyen simple de résoudre ceci, est d'utiliser des couples de clés privés/publiques. Le principe est simple : Nous allons générer une clé privée que nous allons placer sur le client (votre poste) et une clé publique que nous allons mettre sur le serveur (le poste sur lequel vous voulez vous connecter).
La cryptographie asymétrique est une méthode de chiffrement qui s'oppose à la cryptographie symétrique. Elle utilise généralement une clé publique (qui est diffusée) qui permet de coder le message et une clé privée (gardée secrète) qui permet de décoder le message. Ainsi l'expéditeur peut coder le message que seul le destinataire pourra décoder.
Je vous laisse le soin de lire ça suite sur Wikipedia
Commençons par le client, nous allons générer une clé privée :
- Sous Windows :
Commencez par télécharger la suite Putty. Ce qui nous intéresse pour l'instant c'est PuTTY et PuTTYgen qui permet de générer les clés. Ouvrez le et cliquez sur "generate", bougez le curseur dans le cadre indiqué, cela permet créer des valeurs aléatoires. J'ai choisis une clé de 2048bits, mais vous pouvez mettre 1024, cela est amplement suffisant.
Donnez un nom à la clé si vous voulez, cela sera plus facile de les reconnaitre par la suite, le nom s'applique juste à la clé publique. Ensuite mettez une passphrase pour coder votre clé privée et qu'elle ne soit pas utilisable si jamais quelqu'un tombe dessus.
Enregistrez la clé privé sur votre ordinateur, il faudra ensuite l'ajouter dans pageant, la passphrase vous sera demandé. - Sous Linux
Commencez par installer, si cela n'est pas déjà fait de base, openssh-client et placez vous dans le répertoire indiqué :aptitude install openssh-client cd ~/.ssh
Il va falloir maintenant générer les clés grâce à ssh-keygen, l'équivalent de PuTTYgen sous Linux. Voici la commande :
ssh-keygen -t rsa -b 2048 Generating public/private rsa key pair. Enter file in which to save the key (~/.ssh/id_rsa):
- -t permet de spécifier le type (rsa ou dsa)
- -b permet de spécifier le nombre de bits, en l'occurrence, ici 2048 bits
Appuyez sur entrée pour confirmer le choix par défaut du chemin du fichier.
Enter passphrase (empty for no passphrase): Enter same passphrase again:
Comme sous Windows, il est conseillé de rentrer une passphrase pour plus de sécurité. Un jeu de clé va être générer par la suite avec id_rsa comme clé privée et id_rsa.pub pour la clé publique, qu'il faudra mettre sur le serveur.
Nous allons maintenant passer à l'ajout de la clé publique sur le serveur :
- Sous Windows :
Dans la fenêtre où vous avez généré vos clés, copier la clé publique (dans le premier cadre) et coller la sur votre serveur, dans le fichier ~/.ssh/authorized_keys2, attention : il n'y a qu'une clé publique par ligne. Fermez le fichier et c'est fini. - Sous Linux
Sous Linux vous avez deux solutions, soit vous copiez à la main la clé publique contenue dans id_rsa.pub comme sous Windows, soit vous utilisez ssh-copy-id (uniquement pour ssh v1) :ssh-copy-id -i ~/.ssh/id_dsa.pub login@host.com
- -i Indique le chemin du fichier "identity_file" (la clé publique)
NB : Si jamais le port ssh de la machine distante est différent de 22, il faudra alors taper cette commande :
ssh-copy-id -i ~/.ssh/id_dsa.pub "-p 42 login@host.com"
ssh-copy-id étant un script, il lancera ssh avec comme option le 3ème argument, en l'occurrence "-p 42 login@host.com", 42 étant le port d'écoute de ssh sur la machine distante.
ssh-copy-id vous demandera le mot de passe du compte distant pour copier le fichier et vous dira si tout s'est bien passé :
Now try logging into the machine, with "ssh 'login@host.com'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting.
Il ne vous reste plus qu'à faire ce qu'il vous dit :
ssh login@host.com Enter passphrase for key '~/.ssh/id_dsa':
Si vous avez entré une passphrase il vous la demandera comme montré ci-dessus.
Et voilà, c'est magique et ça marche !
Note : Sous Linux, je n'ai pas encore trouvé de réponse pour la question "Est ce qu'on peut mettre les clés privées dans un même fichier ?". Apparemment ce n'est pas possible, il faut préciser quelle clé privée on utilise lors de la connexion avec l'option "-i", ce qui est quand même fort désagréable à la longue. Dans ce cas là il vaut mieux créer des alias, car par exemple pour un script de sauvegarde, je devais faire ça :
sshfs -o port=PORT -o ssh_command="ssh -i /root/.ssh/id_rsa2" backup@xx.xx.xx.xx:/home/backup /mnt/backup/
Une ligne à rallonge... J'éditerai si un jour j'ai la réponse, ou n'hésitez pas à la donner dans un commentaire.
Pour aller plus loin
Pour sécuriser encore plus votre serveur, vous pouvez changer le port d'écoute de ssh comme je l'ai fais, et aussi enlever la demande de mot de passe au moment de la connexion ssh ce qui évite le bruteforce, bien sûr il faut installer les clés privés/publiques avant, sinon cela sera un peu ennuyeu.
- Pour changer le port d'écoute :
emacs /etc/ssh/sshd_config
Changer la ligne #PasswordAuthentication yes par PasswordAuthentication no et relancez ssh :
/etc/init.d/ssh restart
- Pour changer le port d'écoute
Rouvrez le fichier de configuration de ssh :emacs /etc/ssh/sshd_config
Puis rajouter sous "Port 22" "Port XX" (où XX est le port que vous choisirez), puis relancer ssh :
/etc/init.d/ssh restart
Ensuite il va falloir jouer avec iptables pour bloquer le port 22.
Attention : Si votre serveur est hébergez chez un hébergeur type ovh, il faut leur laisser le port 22 !
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 22 --source cache.ovh.net -j ACCEPT
- cache.ovh.net est bien sûr pour ceux qui sont chez ovh
Par contre je vous laisse le soin de bloquer le port 22 pour le reste du monde.
Content de cet article?
Aucun trackbacks pour l'instant
19 avril 2009
J’ai pas la réponse mais j’ai une question, pourquoi ne pas utiliser un bout de papier pour y noter les login et les pass? C’est plus simple encore.
19 avril 2009
Tout simplement parce que c’est pas secure.
Sans compter qu’avec les clés c’est plus rapide de se connecter au serveur, il faut taper la passphrase une première fois mais après plus besoin, c’est transparent.