La plupart des sessions SSH sont authentifiées à l’aide d’un mot de passe. Seulement, ce mode d’authentification a plusieurs inconvénients :

  • Il faut mémoriser son mot de passe, idéalement, un par serveur si on se soucie un minimum de la sécurité ;
  • Il faut le changer régulièrement, toujours dans un souci de sécurité ;
  • Il faut le saisir à chaque connexion ;
  • En cas d’attaque man-in-the-middle, le mot de passe est compromis.

L’authentification par clé asymétrique permet de s’affranchir de tout cela. Les clés sont générées par paire : une clé publique que l’on peut diffuser librement, et une clé privée associée que l’on doit garder bien secrètement. Voici quelques avantages qu’elles procurent :

  • Avec l’utilisation d’un agent, on peut conserver la passphrase en mémoire et éviter de la saisir à chaque connexion, pratique aussi pour des scripts, voir l’article utiliser keychains ;
  • Plusieurs clés publiques peuvent être assignées à un utilisateur, pratique pour des personnes se partageant un même compte root ;
  • Changer de passphrase ne se fait qu’une fois sur sa clé privée, contrairement aux mots de passe qui doivent être changés sur chaque serveur ;
  • La paire de clés est générée aléatoirement contrairement à un mot de passe qui n’est souvent pas aléatoire ;
  • Le serveur ne reçoit ni votre passphrase, ni votre clé privée, mais une réponse à un challenge mathématique, donc une connexion sur un serveur compromis ne compromet pas votre clé privée ;
  • Les clés sont extrêmement difficiles à casser.

Pré requis

Le serveur doit accepter la connexion par clé. La ligne PubKeyAuthentication yes doit être présente dans le fichier de configuration du serveur, généralement /etc/ssh/sshd_config.

Générer la paire de clés

On utilise pour cela la commande ssh-keygen. J’utilise ici une clé RSA de 8192 bits. Oui, c’est énorme, mais au moins, je suis tranquille quelques années.

L’option -C permet de spécifier un commentaire sur sa clé, j’aime bien savoir à quel utilisateur correspond une clé, donc je l’indique ici, c’est une bonne habitude à prendre.

L’option -f permet d’indiquer le nom de la clé privée à générer. C’est également une bonne pratique de générer ses clés dans son répertoire ~/.ssh/.

La génération des clés peut prendre plusieurs minutes. La clé privée doit être protégée par un long mot de passe : une passphrase. Elle doit comporter plusieurs mots, la phrase peut même avoir un sens, tant qu’elle n’est pas écrite sur un post-it, la clé est bien protégée. Le clé privée doit également être sur une machine verrouillée lorsque vous n’êtes pas devant l’écran et elle ne doit être lisible que par vous, afin d’éviter que d’autres utilisateurs du système puissent y avoir accès. Si vous oubliez votre passphrase, il n’y a aucun moyen de la récupérer.

# on crée le répertoire au cas où il n'existe pas
mkdir -p ~/.ssh/
# seul le propriétaire peut lire et écrire dans ce répertoire
chmod 0700 ~/.ssh/

# on génère la clé
ssh-keygen -t rsa -b 8192 -C "ordi perso matthieu" -f ~/.ssh/ma_cle_perso

# on saisit deux fois sa passphrase, rien ne s'affiche, c'est normal.

# on a maintenant notre paire de clés
ls -l ~/.ssh/ma_cle_perso*
-rw-------  1 matthieu  staff  6446  2 oct 22:40 /Users/matthieu/.ssh/ma_cle_perso
-rw-r--r--  1 matthieu  staff  1420  2 oct 22:40 /Users/matthieu/.ssh/ma_cle_perso.pub

Le dossier ~/.ssh/ contient la clé privée ma_cle_perso et sa clé publique correspondante ma_cle_perso.pub.

Installer sa clé publique

Pour autoriser la connexion à un serveur via sa clé privée, il faut au préalable ajouter le contenu de la clé publique correspondante dans le fichier ~/.ssh/authorized_keys de l’utilisateur distant.

Ici, je souhaite installer ma clé ~/.ssh/ma_cle_perso.pub sur le compte matthieu de la machine monserveur.local. Lors de l’installation de la clé publique, le mot de passe du compte sera bien évidemment demandé.

Installer sa clé publique avec ssh-copy-id

Si la commande ssh-copy-id est présente sur votre machine, génial, cette commande sert justement à installer sa clé publique sur un compte distant.

ssh-copy-id -i .ssh/ma_cle_perso.pub [email protected]

# le mot de passe distant vous sera demandé afin de pouvoir installer la clé

Installer sa clé publique sans ssh-copy-id

Si la commande ssh-copy-id n’existe pas, on utilisera cette longue commande à la place.

ssh [email protected] 'mkdir -p ~/.ssh; chmod 0700 ~/.ssh; echo ' $(< ~/.ssh/ma_cle_perso.pub) ' >> ~/.ssh/authorized_keys ; chmod 0600 ~/.ssh/authorized_keys'

Tester la connexion par clé

Une fois la clé publique installée, on peut tester que cette méthode d’authentification fonctionne.

# on peut ensuite tester la connexion avec la clé et sa passphrase
ssh -i ~/.ssh/ma_cle_perso [email protected]

# on n'a plus qu'à saisir sa passphrase

Si vous ne voulez pas saisir à chaque connexion votre passphrase, allez faire un tour sur l’article utiliser keychains.

Envoyer sa clé publique à un administrateur

Il peut arriver qu’on ne puisse pas installer directement sa clé sur une machine et qu’on doive la donner à un administrateur afin qu’il l’installe lui-même sur le serveur. Il est possible que la clé soit interceptée et remplacée par celle d’une personne malintentionnée. Ainsi, la bonne pratique consiste à vérifier par téléphone avec son interlocuteur que la clé publique reçue par email est bien celle envoyée, en vérifiant par exemple sa somme de contrôle SHA256.

Alors que vous êtes au téléphone, chacun de son côté saisit la commande suivante, afin de vérifier que l’empreinte SHA256 n’a pas changé pendant le voyage.

ssh-keygen -E sha256 -lf ~/.ssh/ma_cle_perso.pub
8192 SHA256:PYdgMViJ7OrcL8bVBV0aAsJkglFS7w9xDazNAMxWd84 mon ordi perso (RSA)

Durant cet appel, l’administrateur pourrait également vous dicter l’empreinte du serveur afin que vous puissiez la vérifier lors de la première connexion.

Changer sa passphrase

Si on souhaite changer sa passphrase, rien de plus simple, on saisit la commande suivante. L’ancienne passphrase nous est d’abord demandée, ensuite on saisit deux fois la nouvelle.

ssh-keygen -p -f ~/.ssh/ma_cle_perso

C’est tout, même pas besoin de redéployer sa clé publique.

Que faire si la clé privée est compromise ?

Si vous avez opté pour une clé privée sans passphrase et que vous pensez que quelqu’un a récupéré votre clé privée, votre clé privée est compromise. Il faut toujours mettre une passphrase sur vos clés privées, je vous l’ai dit au début de cet article.

Si quelqu’un a vu votre passphrase, votre clé privée peut potentiellement être compromise si l’individu a réussi à récupérer le fichier contenant la clé privée. Si vous pensez que ce n’est pas le cas, votre clé n’est pas compromise. Allez vite changer votre passphrase. Si vous pensez qu’il a réussi à récupérer le fichier, alors votre clé est compromise.

Si vous pensez que quelqu’un a récupéré le fichier contenant votre clé privée, et que celle-ci est protégée par une passphrase, en théorie, elle n’est pas compromise. Sur un serveur géré par un administrateur, votre clé privée peut être lue par root, mais elle est protégée par sa passphrase, et de toutes façons, vous faites confiance à l’administrateur, non ? Une personne malintentionnée pourrait finir par trouver la passphrase via une attaque brute force mais pas avant plusieurs années.

En cas de compromission de la clé privée, que faut-il faire ?

  • Regénérer une nouvelle paires de clés ;
  • Redéployer la nouvelle clé publique sur tous les serveurs ;
  • Révoquer la clé publique sur tous les serveurs où elle est présente, c’est-à-dire supprimer la ligne correspondant à votre clé publique dans le fichier ~/.ssh/authorized_keys et en même temps vérifier que d’autres clés publiques non légitimes n’ont pas été ajoutées ;
  • Si la clé publique était présente sur un compte root, il va falloir faire un audit complet du serveur car il peut potentiellement avoir été compromis, bonne chance.

J’utilise personnellement plusieurs clés privées, une (ou plusieurs) par machine et serveur personnels, une au travail, une sur mon téléphone, etc. Ceci me permet de révoquer finement une clé publique si je considère que la clé privée correspondante a pu être compromise. De plus, toutes les clés n’ont pas forcément accès aux mêmes machines, par exemple, au travail, je ne veux pas pouvoir accéder à mes serveurs personnels, il me suffit de ne pas installer ma clé publique travail sur ces machines.