Suite de l'article : Automatiser l'administration de votre serveur Ubuntu par ssh - partie 1
N.B. : je ne détaille pas certaines choses, comme le transfert du fichier de la clé publique par exemple, car je considère que si vous appliquez ce tutoriel, vous possédez déjà certaines connaissances avancées. Si ce n'est pas le cas, je vous conseille de ne pas aller plus loin car les manipulations ci-dessous peuvent compromettre la sécurité de vos systèmes si elles sont mal appliquées ou mal comprises.
L'attente fut longue, mais voilà enfin la suite et fin de ce tutoriel ! Après avoir vu comment simplifier l'administration de ses machines par ssh via l'utilisation de scripts shell, nous allons voir comment aller encore plus loin en utilisant l'authentification par clés pour ssh.
Les identités SSH
Les identités SSH sont ce qui permet de prouver votre identité à un serveur SSH. Une identité est formée de deux parties, la clé privée et la clé publique, elles forment une paire de clés.
La clé privée permet à un client SSH de prouver son identité au serveur SSH auquel il veut se connecter. Le serveur SSH examine alors la clé publique correspondante qu'il a en sa possession, et, par un test cryptographique, si les clés correspondent, la connexion réussit.
La clée privée doit absoluement être gardée secrète. Une personne en possession de cette clé privée pourrait se connecter à vos comptes aussi facilement que vous.
La clé publique n'a pas besoin d'être secrète, elle ne peut pas servir à pénétrer par effraction dans votre compte.
Génération de son identité
Rien de plus simple, tapez dans un terminal :
ssh-keygen -t dsa
Le programme vous demande à quel endroit enregistrer la clé, laissez le choix par défaut.
Ensuite on vous demande une passphrase, il s'agit d'un mot de passe protégeant la clé privée. Pour pouvoir vous logguer sans avoir à rentrer de mot de passe, ne rentrez rien, validez par la touche entrée (deux fois). Nous verrons plus loin comment mieux sécuriser celà .
La clé privée est donc générée sous ~/.ssh/id_dsa, et la clé publique sous ~/.ssh/id_dsa.pub.
Envoi de la clé publique sur le serveur SSH
Tout d'abord, envoyez le fichier ~/.ssh/id_dsa.pub sur le serveur distant, par exemple par FTP, dans le répertoire racine de l'utilisateur sur lequel vous voulez vous connecter sur le serveur.
Il faut ensuite rentrer cette clé dans le fichier ~/.ssh/authorized_keys sur le serveur. Connectez-vous en ssh par la manière traditionnelle dessus, et tapez la commande suivante :
cat ~/id_dsa.pub >> ~/.ssh/authorized_keys
Puis effacez le fichier de clé publique transféré précédemment par le moyen de votre choix : rm ~/id_dsa.pub
Test de connexion
Allez, hop, on peut tester la connexion et vérifier que ssh ne nous demande plus de mot de passe : ssh user@machine.com
Normalement, ça fonctionne sans problème si vous avez bien suivi les instructions ci-dessus !
Variante avec passphrase et utilisation de ssh-agent
Si quelqu'un vous vole votre clé privée, comme elle ne possède pas de passphrase la protégeant, le voleur pourra l'utiliser pour se connecter sur votre serveur SSH. Pour résoudre ce problème, il vous suffit de donner une passphrase au moment de la génération de votre identité (ssh-keygen -t dsa). Je vous conseille de mettre une passphrase assez longue, en utilisant des moyens mémotechniques comme les premières lettres de chaque mot d'une longue phrase, ou en supprimant les voyelles, et en mixant les majuscules/minuscules, chiffres et caractères spéciaux.
Le point négatif de la passphrase est qu'il faut la fournir pour déverrouiller la clé privée avant la connexion ssh, on revient donc en arrière au niveau ergonomique. C'est là que le programme ssh-agent va nous aider !
Et la magie d'Ubuntu et Gnome opère : gnome-keyring intègre ssh-agent, normalement c'est activé par défaut, en tout cas dans la version 9.04 d'Ubuntu. Pour faire simple, redémarrer votre pc et lors de la première connexion au serveur SSH, la passphrase vous sera demandée via une fenêtre graphique pour la seule et unique fois (jusqu'au prochain reboot de votre PC, bien sur). C'est un moindre mal : auparavant il fallait donner un mot de passe à chaque connexion ssh, désormais il ne faut plus donner qu'une seule fois une passphrase.
Conclusion
Certains vont encore plus loin dans l'utilisation des identités SSH. Pour sécuriser au maximum l'accès à certains serveurs, l'authentification par mot de passe est désactivé, il faut obligatoirement utiliser une paire de clés SSH. Ca rajoute des contraintes, mais c'est le prix de la sécurité.
Associé avec la création de scripts comme on l'a vu dans le premier article, l'utilisation de clés SSH peut simplifier énormément la vie. Mais il faut rester prudent dans l'utilisation de ces techniques car une mauvaise utilisation pourrait compromettre la sécurité de vos systèmes, en particulier en cas de vol de votre clé privée.
