Matthieu Petiot modifié le
SysAdmin macos , linux , ssh , ssh-keygen , shell

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 keychain ;
  • 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.

Le format de clé SSH recommandé actuellement est le format ED25519. Il est préféré pour plusieurs raisons :

  • Sécurité : Les clés ED25519 sont basées sur l’algorithme de courbe elliptique, offrant une sécurité élevée avec des tailles de clé plus petites par rapport aux clés RSA ;
  • Performance : Elles sont plus rapides pour la génération et l’utilisation, ce qui réduit le temps de calcul et la charge sur le système ;
  • Robustesse : Elles offrent une meilleure protection contre certaines attaques cryptographiques modernes.

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.

Le serveur SSH doit également permettre la connexion avec une clé de ce type. Vous pouvez vérifier cela avec le client SSH.

ssh -Q key -F /dev/null [email protected]

Si la sortie affiche une ligne ssh-ed25519 alors c’est bon, dans le cas contraire, il faudra définir sur le serveur l’option PubkeyAcceptedAlgorithms à ssh-ed25519 en plus des autres formats attendus sauf si vous ne voulez que ce format.

Un redémarrage du serveur SSH est requis si vous changez sa configuration.

Générer la paire de clés

On utilise pour cela la commande ssh-keygen.

On crée ici une clé ED25519 grâce à l’option -t ed25519.

L’option -a permet d’indiquer le nombre d’itérations de bcrypt, ce qui renforce la sécurité de la passphrase protégeant la clé privée. Par défaut, il s’agit de 16 itérations. On passe à 1000 ici, ce qui augmente le temps du déchiffrement de la clé privée mais rend plus difficile une attaque brute force mais si vous utilisez keychain, ces quelques secondes (environ 5) d’attente n’ont lieu qu’au moment de la première authentification.

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 ed25519 -a 1000 -C "ordi perso matthieu" -f $HOME/.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. Le fichier ma_cle_perso.pub peut être diffusé au monde entier, en revanche, ma_cle_perso doit être conservé précieusement dans un endroit sûr. Ce fichier contient la clé privée chiffrée si vous avez choisi d’utiliser une passphrase, dans le cas contraire, elle est en clair et c’est un très mauvais choix.

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 keychain.

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. Il faut bien penser à mettre -a 1000 sinon on est sur une valeur par défaut de 16.

ssh-keygen -a 1000 -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 passphrase vide et que vous pensez que quelqu’un a récupéré votre fichier de clé privée, votre clé privée est compromise. IL FAUT TOUJOURS METTRE UNE PASSPHRASE SUR VOS CLÉS PRIVÉES.

Si vous pensez que quelqu’un a vu votre passphrase, changez la immédiatement ; pour rappel, il n’est pas nécessaire de redéployer la clé publique.

Si vous pensez que le fichier de clé privée a pu être récupéré également, alors votre clé privée est compromise.

Si vous pensez que quelqu’un a récupéré votre fichier de clé privée, en théorie, elle n’est pas compromise tant que la passphrase n’a pas été trouvée, mais il faut considérer qu’elle est compromise car une personne malintentionnée finira par trouver la passphrase via une attaque brute force mais pas avant plusieurs années sauf s’il dispose d’une force de calcul élevée.

Faites également attention lorsque vous utilisez une clé privée depuis un serveur qui n’est pas le vôtre, un administrateur a tous les droits et peut donc récupérer votre fichier de clé privée.

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. Il est parfois plus simple de récupérer les données sensibles et faire une réinstallation propre.

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.