Gestion des clés SSH : les bases

Comment fonctionnent les clés SSH

Une clé SSH est une paire de fichiers : une clé privée qui reste sur votre appareil et une clé publique que vous copiez sur chaque serveur où vous voulez vous connecter. Lorsque vous vous connectez, le serveur utilise la clé publique pour envoyer un défi auquel seule la clé privée correspondante peut répondre. La clé privée ne quitte jamais votre appareil : aucun secret ne circule sur le réseau, et un serveur compromis n'a rien d'utile à voler. C'est pourquoi les clés valent mieux que les mots de passe. Bien gérer ses clés SSH tient en quatre habitudes : une clé par appareil, les permissions de fichiers exigées par sshd, un fichier ~/.ssh/config pour ne plus taper d'options, et savoir supprimer une clé le jour où un ordinateur portable disparaît.

Ce guide traite chaque habitude sur Ubuntu 24.04, même si presque tout ce qui suit s'applique à n'importe quel serveur Linux et à n'importe quelle version récente d'OpenSSH.

Un point de vocabulaire avant de commencer, car il évite de vraies erreurs. La clé publique n'est pas secrète. Vous pouvez la coller dans un ticket, l'envoyer par e-mail ou la publier, personne ne pourra se connecter avec elle. La clé privée, c'est le secret. Quiconque copie ce fichier, et connaît sa phrase secrète s'il en a une, est vous aux yeux de vos serveurs.

Créer une clé : ed25519 est le bon choix par défaut

Sur votre propre ordinateur, pas sur le serveur, exécutez :

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 choisit le type de clé. Ed25519 est la valeur par défaut moderne : les clés sont courtes, rapides et prises en charge par toutes les versions d'OpenSSH depuis 2014. Revenez à ssh-keygen -t rsa -b 4096 uniquement lorsque vous devez communiquer avec un vieil appareil qui ne comprend pas ed25519. -C "laptop" définit un commentaire. Le commentaire n'a aucun rôle cryptographique, mais c'est ainsi que vous reconnaîtrez cette clé dans le fichier authorized_keys d'un serveur dans deux ans : nommez donc l'appareil sur lequel vit la clé.

ssh-keygen demande où enregistrer la clé. Acceptez la valeur par défaut, ~/.ssh/id_ed25519. Il demande ensuite une phrase secrète. Définissez-en une ; la section sur les phrases secrètes ci-dessous explique pourquoi cela ne vous coûte rien au quotidien. Vous obtenez deux fichiers : ~/.ssh/id_ed25519 est la clé privée, et ~/.ssh/id_ed25519.pub est la clé publique. Regardez la moitié publique :

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

C'est une seule ligne : le type de clé, le matériel de la clé et votre commentaire. C'est cette ligne qui se retrouve sur vos serveurs.

Une clé par appareil, pas une par serveur

La question que tout le monde pose en premier : ai-je besoin d'une nouvelle clé pour chaque serveur ? Non. Créez une clé pour chaque appareil sur lequel vous tapez, et placez cette unique clé publique sur chaque serveur que l'appareil doit atteindre. La clé identifie l'appareil. Le fichier authorized_keys de chaque serveur est la liste des appareils autorisés à entrer.

C'est le modèle qui passe à l'échelle, et les autres échouent de façon prévisible. Une clé par serveur signifie qu'un ordinateur portable avec vingt serveurs porte vingt clés privées, et vous finirez par ne plus savoir laquelle est laquelle. Une seule clé partagée par tous vos appareils est pire : lorsque l'ordinateur portable est volé, vous ne pouvez pas révoquer le portable sans aussi bloquer votre ordinateur de bureau, car ils détiennent la même clé privée ; vous devez donc remplacer la clé partout et la redistribuer à tous les appareils en même temps.

Avec une clé par appareil, l'ordinateur portable perdu ne vous coûte qu'une ligne par serveur : supprimez la ligne du portable dans authorized_keys, et tous les autres appareils continuent de fonctionner. Le commentaire que vous avez défini avec -C est ce qui rend cette ligne facile à trouver.

La règle derrière ce modèle : une clé privée est créée sur un appareil et meurt avec cet appareil. Ne copiez jamais une clé privée sur une deuxième machine, et n'en téléversez jamais une sur un serveur. Lorsqu'un nouvel appareil a besoin d'un accès, générez une nouvelle clé dessus.

Placer la clé publique sur le serveur

La méthode simple est ssh-copy-id, livré avec OpenSSH :

ssh-copy-id matt@10.0.0.10

Il se connecte avec ce qui fonctionne encore, en général un mot de passe, ajoute votre clé publique à ~/.ssh/authorized_keys sur le serveur, et crée le répertoire et le fichier avec les bonnes permissions s'ils manquent. Testez en ouvrant une nouvelle session SSH : le serveur devrait vous laisser entrer sans demander le mot de passe du compte. Si votre clé a une phrase secrète, votre propre machine peut la demander à la place ; cette invite est locale et n'est pas le mot de passe du serveur.

Lorsque la connexion par mot de passe est déjà désactivée, ssh-copy-id ne peut pas entrer : vous ajoutez donc la ligne à la main. Connectez-vous via une session qui fonctionne encore, ou la console web de votre hébergeur, et exécutez ceci sur le serveur :

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Collez votre vraie clé publique entre les guillemets, la ligne unique complète de id_ed25519.pub. authorized_keys contient une clé publique par ligne, et c'est toute la base de données des accès : ajouter un appareil, c'est ajouter une ligne, et révoquer un appareil, c'est en supprimer une. Sur un serveur tout neuf, cette étape a sa place dans les 10 premières minutes sur un nouveau VPS, juste avant de désactiver la connexion par mot de passe.

Les permissions qui cassent la connexion par clé

C'est la cause la plus fréquente d'échec de la connexion par clé, et elle échoue en silence côté client. sshd s'exécute avec StrictModes yes par défaut sur Ubuntu 24.04, ce qui signifie qu'il refuse d'utiliser un fichier authorized_keys que d'autres utilisateurs pourraient modifier. Si le fichier, le répertoire ~/.ssh ou votre répertoire personnel peut être écrit par quelqu'un d'autre que vous, sshd ignore votre clé et retombe sur la demande d'un mot de passe, sans aucune explication côté client. (L'OpenSSH d'Ubuntu tolère exactement un cas étroit : un fichier accessible en écriture par votre propre groupe privé, dans lequel personne d'autre ne se trouve. Ne comptez pas dessus ; gardez les modes ci-dessous.) La raison n'apparaît que dans le journal du serveur :

sudo grep 'Authentication refused' /var/log/auth.log

Sur une image minimale sans rsyslog, il n'y a pas d'auth.log ; la même ligne se trouve dans le journal : sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

La correction consiste en deux changements de permissions et une vérification de propriété, à exécuter sur le serveur en tant qu'utilisateur concerné :

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

La règle à retenir : 700 sur le répertoire .ssh, 600 sur tout ce qu'il contient. Les mêmes nombres s'appliquent sur votre propre ordinateur, car le client vérifie aussi. Une clé privée lisible par d'autres utilisateurs pousse ssh à refuser la clé purement et simplement, et cette fois l'erreur est bruyante :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 corrige le problème.

~/.ssh/config : arrêter de taper des options

Un fichier ~/.ssh/config sur votre propre ordinateur donne à chaque serveur un nom court et retient les options que vous tapez sans cesse. Créez-le avec des permissions 600 et ajoutez un bloc Host par serveur :

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Désormais ssh web1 remplace ssh -p 22 matt@10.0.0.10, et le même nom court fonctionne dans scp, rsync et git, car ils lisent tous ce fichier. HostName est l'adresse réelle, User vous évite de taper le nom du compte, et IdentityFile fixe la clé à proposer.

IdentitiesOnly yes mérite une phrase, car il corrige une panne déroutante. Lorsque votre agent détient plusieurs clés, le client les propose une par une, et le serveur compte chaque proposition comme une tentative échouée. Avec assez de clés chargées, vous obtenez Received disconnect: Too many authentication failures avant même que la bonne clé ne soit essayée. IdentitiesOnly yes fait en sorte que le client ne propose que la clé nommée dans IdentityFile, de sorte que la panne ne peut pas se produire.

Phrases secrètes et ssh-agent

Une phrase secrète chiffre le fichier de la clé privée sur le disque. Sans elle, quiconque copie le fichier peut l'utiliser immédiatement ; avec elle, le fichier volé est inutile tant que la phrase secrète n'est pas devinée. Pour une clé sur un ordinateur portable, c'est exactement la protection que vous voulez, car les portables se font voler et les sauvegardes de portables fuient.

La raison pour laquelle une phrase secrète ne coûte rien en pratique, c'est ssh-agent. L'agent garde votre clé déchiffrée en mémoire : vous tapez la phrase secrète une fois par session de connexion et chaque connexion ultérieure est instantanée. La plupart des distributions Linux de bureau et macOS exécutent déjà un agent pour vous. Chargez-y votre clé avec :

ssh-add ~/.ssh/id_ed25519

ssh-add -l liste les clés que l'agent détient actuellement. Une mise en garde : le transfert d'agent (ssh -A) permet au serveur distant d'utiliser votre agent pour s'authentifier plus loin tant que vous êtes connecté ; ne l'activez donc que vers des serveurs auxquels vous faites entièrement confiance, et laissez-le désactivé par défaut.

Rotation et révocation : l'exercice du portable perdu

Révoquer une simple clé SSH n'est rien de plus que supprimer sa ligne dans authorized_keys sur chaque serveur qui la possède. Il n'y a aucune autorité de certification à prévenir ni date d'expiration à attendre. Dès que la ligne a disparu, les nouvelles connexions avec cette clé échouent.

Faites l'exercice maintenant, tant que ce n'est pas une urgence. Choisissez un serveur, ouvrez ~/.ssh/authorized_keys, et trouvez la clé par son commentaire. Supprimez la ligne avec un éditeur, ou filtrez-la par commentaire :

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

Confirmez ensuite, depuis l'appareil que vous venez de révoquer, que la connexion échoue maintenant, et depuis un autre appareil que la connexion fonctionne toujours. Notez un détail : supprimer une clé ne ferme pas les sessions déjà ouvertes, car la clé n'est vérifiée qu'à la connexion. Si vous révoquez un appareil volé, vérifiez aussi who sur le serveur et mettez fin à toute session que vous ne reconnaissez pas.

La rotation est la même opération dans un ordre différent : générez une nouvelle clé sur l'appareil, installez-la avec ssh-copy-id, confirmez que la nouvelle clé permet de se connecter, puis supprimez l'ancienne ligne. Faites-le quand un appareil change de mains, quand une clé a pu être exposée, ou quand quelqu'un quitte une équipe. Le faire à la main sur deux serveurs est acceptable ; sur vingt, c'est un travail pour l'automatisation, et gérer plusieurs serveurs Linux montre comment pousser le même état authorized_keys vers toute une flotte.

Ce qu'il ne faut pas faire

• Ne partagez pas une seule clé privée entre tous vos appareils. Cela rend impossible la révocation d'un seul appareil volé sans remplacer la clé partout.

• Ne validez pas une clé privée dans un dépôt git, même privé. Des scanners automatisés surveillent les dépôts publics et essaient les clés fuitées dans les minutes qui suivent un push, et un dépôt rendu public plus tard fait fuiter tout son historique.

• Ne téléversez pas la clé privée de votre portable sur un serveur pour que ce serveur puisse en atteindre un autre. Générez une clé distincte sur le serveur lui-même, et autorisez cette clé exactement là où elle est nécessaire.

• Ne collez pas une clé privée dans une messagerie, un e-mail ou un ticket. La clé publique, le fichier .pub, est la seule moitié qui se partage.

Une fois que votre clé vous connecte de façon fiable, passez à l'étape suivante et désactivez l'authentification par mot de passe, pour que le devinage constant contre votre serveur ne puisse pas réussir du tout. La configuration prête à l'emploi pour cela se trouve dans le durcissement SSH sur un VPS.

FAQ

Comment fonctionnent les clés SSH sans envoyer de mot de passe ?

Le serveur conserve votre clé publique dans ~/.ssh/authorized_keys. À la connexion, il envoie un défi, votre client signe le défi avec la clé privée, et le serveur vérifie la signature avec la clé publique. La clé privée ne quitte jamais votre appareil : il n'y a donc rien à intercepter en transit ni rien de réutilisable à voler sur le serveur. Un serveur piraté ne fait fuiter que des clés publiques, qui ne peuvent servir à se connecter nulle part.

Dois-je utiliser la même clé SSH pour tous mes serveurs ?

Utiliser une clé sur plusieurs serveurs est correct, tant que cette clé reste sur un seul appareil. La règle est une clé par appareil, pas une par serveur : la clé publique de votre portable va sur chaque serveur dont le portable a besoin, et votre ordinateur de bureau a sa propre clé. Cela garde la révocation simple, car perdre un appareil revient à supprimer une ligne identifiable sur chaque serveur, et les autres appareils continuent de fonctionner.

Quelles permissions pour le répertoire .ssh et authorized_keys ?

Mettez 700 sur ~/.ssh et 600 sur authorized_keys et sur chaque clé privée, appartenant au compte qui les utilise. sshd s'exécute avec StrictModes yes par défaut : un fichier ou un répertoire personnel que quelqu'un d'autre que vous peut écrire lui fait ignorer votre clé en silence, et la seule trace est Authentication refused: bad ownership or modes dans le journal d'authentification ou le journal du serveur.

Comment supprimer une clé SSH d'un serveur ?

Supprimez la ligne de la clé dans ~/.ssh/authorized_keys du compte pour lequel elle était autorisée. Trouvez la bonne ligne par son commentaire, l'étiquette après le matériel de la clé. Les nouvelles connexions avec cette clé échouent immédiatement, mais les sessions déjà ouvertes le restent : mettez donc aussi fin à toute session active pour cet appareil s'il a été volé. Répétez sur chaque serveur où la clé a été copiée.

Ai-je besoin d'une phrase secrète sur ma clé SSH ?

Pour une clé sur un ordinateur portable ou de bureau, oui. La phrase secrète chiffre le fichier de la clé, si bien qu'une copie volée ou fuitée est inutile à elle seule, et ssh-agent fait que vous la tapez une fois par session plutôt qu'à chaque connexion. Les clés utilisées par l'automatisation sans surveillance sur un serveur n'ont en général pas de phrase secrète, car aucun humain n'est présent pour en taper une ; protégez-les en limitant ce que le compte cible peut faire.