Clés SSH : les gérer correctement sur Linux

Fonctionnement des 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 auquel vous voulez vous connecter. Lors de la connexion, 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 donc sur le réseau, et un serveur compromis n’a rien d’utile à voler. C’est pourquoi les clés sont plus sûres que les mots de passe. Une bonne gestion des clés SSH repose sur quatre habitudes : une clé par appareil, les permissions de fichier exigées par sshd, un fichier ~/.ssh/config pour ne plus saisir les options, et la capacité à supprimer une clé dès qu’un ordinateur portable disparaît.

Ce guide présente chacune de ces habitudes sur Ubuntu 24.04. Presque tout ce qui suit s’applique toutefois à n’importe quel serveur Linux et à toute version récente d’OpenSSH.

Un point de vocabulaire avant de commencer, car il évite des erreurs concrètes. La clé publique n’est pas secrète. Vous pouvez la copier dans un ticket, l’envoyer par e-mail ou la publier : personne ne peut se connecter avec elle. La clé privée est le secret. Toute personne qui copie ce fichier et connaît sa passphrase, s’il en a une, peut se faire passer pour vous auprès de vos serveurs.

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

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

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 sélectionne le type de clé. Ed25519 est le choix moderne par défaut : les clés sont courtes, rapides et prises en charge par toutes les versions d’OpenSSH sorties depuis 2014. Utilisez ssh-keygen -t rsa -b 4096 uniquement si vous devez vous connecter à un ancien appareil qui ne comprend pas ed25519. -C "laptop" définit un commentaire. Le commentaire n’a aucune fonction cryptographique, mais il vous permettra d’identifier cette clé dans le fichier authorized_keys d’un serveur dans deux ans. Indiquez donc le nom de l’appareil sur lequel la clé est stockée.

ssh-keygen demande où enregistrer la clé. Acceptez la valeur par défaut, ~/.ssh/id_ed25519. Le programme demande ensuite une phrase secrète. Définissez-en une ; la section suivante explique pourquoi cela ne vous fera rien perdre au quotidien. Vous obtenez deux fichiers : ~/.ssh/id_ed25519 est la clé privée et ~/.ssh/id_ed25519.pub est la clé publique. Affichez la partie publique :

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Elle tient sur une seule ligne : le type de clé, le matériau cryptographique et votre commentaire. C’est cette ligne qui sera copiée sur vos serveurs.

Une clé par appareil, pas une clé par serveur

La première question est toujours la même : faut-il une nouvelle clé pour chaque serveur ? Non. Créez une clé pour chaque appareil depuis lequel vous saisissez des commandes, puis ajoutez cette clé publique à chaque serveur auquel l’appareil doit accéder. La clé identifie l’appareil. Le fichier authorized_keys de chaque serveur contient la liste des appareils autorisés.

C’est le modèle qui passe à l’échelle. Les autres approches échouent de manière prévisible. Une clé par serveur signifie qu’un ordinateur portable utilisé avec vingt serveurs contient vingt clés privées, et vous finirez par ne plus savoir laquelle correspond à quel serveur. Une clé partagée par tous vos appareils est encore pire : si l’ordinateur portable est volé, vous ne pouvez pas révoquer son accès sans bloquer aussi votre ordinateur de bureau, car les deux appareils possèdent la même clé privée. Vous devez donc remplacer la clé partout et la redistribuer simultanément sur chaque appareil.

Avec une clé par appareil, la perte de l’ordinateur portable vous coûte une ligne par serveur : supprimez la ligne de l’ordinateur portable dans authorized_keys, et tous les autres appareils continuent de fonctionner. Le commentaire que vous définissez avec -C permet de retrouver facilement cette ligne.

La règle qui sous-tend ce modèle est simple : une clé privée est créée sur un appareil et disparaît avec lui. Ne copiez jamais une clé privée sur une autre machine et n’en téléversez jamais une sur un serveur. Lorsqu’un nouvel appareil doit accéder aux serveurs, générez une nouvelle clé sur cet appareil.

Placez la clé publique sur le serveur

La méthode la plus simple consiste à utiliser ssh-copy-id, fourni avec OpenSSH :

ssh-copy-id matt@10.0.0.10

Cette commande se connecte avec ce qui fonctionne encore, généralement un mot de passe, ajoute votre clé publique à ~/.ssh/authorized_keys sur le serveur et crée le répertoire ainsi que le fichier avec les permissions correctes s’ils sont absents. Testez la configuration en ouvrant une nouvelle session SSH : le serveur doit vous laisser vous connecter sans demander le mot de passe du compte. Si votre clé possède une passphrase, votre propre machine peut demander celle-ci à la place. Cette invite est locale ; il ne s’agit pas du mot de passe du serveur.

Lorsque la connexion par mot de passe est déjà désactivée, ssh-copy-id ne peut pas se connecter. Vous devez donc ajouter la ligne manuellement. Connectez-vous avec une session qui fonctionne encore ou avec la console web de votre fournisseur, puis exécutez cette commande sur le serveur :

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

Collez votre véritable clé publique entre les guillemets, sur la ligne complète provenant de id_ed25519.pub. authorized_keys contient une clé publique par ligne et constitue toute la base des accès : ajouter un appareil consiste à ajouter une ligne, et révoquer l’accès d’un appareil consiste à en supprimer une. Sur un serveur neuf, cette étape doit être réalisée dans les 10 premières minutes sur un nouveau VPS, juste avant de désactiver la connexion par mot de passe.

Les permissions qui empêchent l’authentification par clé

C’est la cause la plus fréquente d’échec de l’authentification par clé. Depuis le client, l’échec est silencieux. Par défaut, sshd s’exécute avec StrictModes yes sur Ubuntu 24.04. Il refuse donc d’utiliser un fichier authorized_keys que d’autres utilisateurs pourraient modifier. Si le fichier, le répertoire ~/.ssh ou votre répertoire personnel peuvent être modifiés par un autre utilisateur que vous, sshd ignore votre clé et demande un mot de passe, sans fournir d’explication au client. (L’OpenSSH d’Ubuntu tolère exactement un cas particulier : un fichier inscriptible par le groupe privé auquel vous appartenez, si aucun autre utilisateur n’en fait partie. Ne vous appuyez pas sur ce comportement ; utilisez les modes indiqués ci-dessous.) La cause apparaît uniquement dans le journal du serveur :

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

Sur une image minimale sans rsyslog, le fichier auth.log n’existe pas. La même ligne se trouve dans le journal systemd : sudo journalctl -u ssh | grep 'Authentication refused'.

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

Pour corriger le problème, modifiez deux permissions et vérifiez le propriétaire. Exécutez ces commandes sur le serveur avec le compte de l’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 son contenu. Les mêmes valeurs s’appliquent sur votre propre ordinateur, car le client vérifie également ces permissions. Si d’autres utilisateurs peuvent lire une clé privée, ssh refuse entièrement de l’utiliser. Dans ce cas, l’erreur est explicite :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         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 : ne retapez plus les options

Un fichier ~/.ssh/config sur votre propre ordinateur attribue un nom court à chaque serveur et mémorise les options que vous retapez régulièrement. Créez-le avec les 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. Le même nom court fonctionne dans scp, rsync et git, car ces outils lisent tous ce fichier. HostName indique l’adresse réelle, User vous évite de retaper le nom du compte et IdentityFile définit la clé à proposer.

IdentitiesOnly yes mérite une explication, car cette option corrige un problème déroutant. Lorsque votre agent contient plusieurs clés, le client les propose l’une après l’autre, et le serveur compte chaque proposition comme une tentative échouée. Si suffisamment de clés sont chargées, vous obtenez Received disconnect: Too many authentication failures avant même que la bonne clé soit proposée. IdentitiesOnly yes oblige le client à proposer uniquement la clé indiquée dans IdentityFile, ce qui empêche ce problème.

Phrase secrète et ssh-agent

Une phrase secrète chiffre le fichier de clé privée sur le disque. Sans phrase secrète, toute personne qui copie le fichier peut l’utiliser immédiatement. Avec une phrase secrète, le fichier volé est inutilisable tant que celle-ci n’a pas été devinée. Pour une clé stockée sur un ordinateur portable, c’est exactement la protection recherchée, car les ordinateurs portables sont volés et leurs sauvegardes peuvent fuiter.

La raison pour laquelle une phrase secrète ne vous gêne pratiquement pas est ssh-agent. L’agent conserve votre clé déchiffrée en mémoire. Vous saisissez donc la phrase secrète une seule fois par session de connexion, puis toutes les connexions suivantes sont immédiates. 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 affiche les clés actuellement conservées par l’agent. Attention toutefois : l’agent forwarding (ssh -A) permet au serveur distant d’utiliser votre agent pour s’authentifier auprès d’autres serveurs pendant votre connexion. Activez donc cette fonction uniquement vers des serveurs auxquels vous accordez une confiance totale et laissez-la désactivée par défaut.

Rotation et révocation : procédure en cas d’ordinateur portable perdu

Révoquer une clé SSH classique consiste simplement à supprimer sa ligne de authorized_keys sur chaque serveur qui la contient. Il n’y a aucune autorité de certification à prévenir ni date d’expiration à attendre. Dès que la ligne est supprimée, les nouvelles connexions avec cette clé échouent.

Effectuez cette procédure maintenant, en dehors de toute urgence. Choisissez un serveur, ouvrez ~/.ssh/authorized_keys et recherchez la clé à l’aide de son commentaire. Supprimez la ligne avec un éditeur ou filtrez-la à partir du commentaire :

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

Vérifiez ensuite, depuis l’appareil que vous venez de révoquer, que la connexion échoue et, depuis un autre appareil, qu’elle fonctionne toujours. Point important : supprimer une clé ne ferme pas les sessions déjà ouvertes, car la clé n’est vérifiée qu’au moment de la connexion. Si vous révoquez un appareil volé, vérifiez également who sur le serveur et mettez fin à toute session que vous ne reconnaissez pas.

La rotation repose sur 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, vérifiez que la nouvelle clé permet la connexion, puis supprimez l’ancienne ligne. Effectuez cette opération lorsqu’un appareil change de propriétaire, lorsqu’une clé a pu être compromise ou lorsqu’une personne quitte une équipe. La gestion manuelle convient pour deux serveurs ; pour vingt serveurs, il faut automatiser, et gérer plusieurs serveurs Linux explique comment déployer le même état authorized_keys sur toute une flotte.

Ce qu’il ne faut pas faire

• Ne partagez pas une seule clé privée entre tous vos appareils. Vous ne pourrez pas révoquer 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 divulguées dans les minutes qui suivent un push. Si le dépôt devient public ultérieurement, tout son historique est exposé.

• Ne téléversez pas la clé privée de votre ordinateur portable sur un serveur pour permettre à ce serveur d’atteindre un autre serveur. Générez une clé distincte directement sur le serveur, puis autorisez cette clé exactement là où elle est nécessaire.

• Ne collez pas une clé privée dans une conversation, un e-mail ou un ticket. La clé publique, le fichier .pub, est la seule partie qui doit être partagée.

Une fois que votre clé vous connecte de manière fiable, désactivez l’authentification par mot de passe. Les tentatives constantes de deviner le mot de passe de votre serveur ne pourront alors plus aboutir. La configuration prête à l’emploi correspondante se trouve dans Renforcer la sécurité de SSH sur un VPS.

FAQ

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

Le serveur conserve votre clé publique dans ~/.ssh/authorized_keys. Lors de la connexion, il envoie un challenge. Votre client signe ce challenge avec la clé privée, puis 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 pendant le transit et rien de réutilisable à voler sur le serveur. Un serveur compromis ne divulgue que des clés publiques, qui ne permettent pas de se connecter ailleurs.

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

Utiliser une seule clé sur plusieurs serveurs est correct, à condition qu’elle reste sur un seul appareil. La règle est une clé par appareil, et non une clé par serveur : la clé publique de votre laptop est copiée sur chaque serveur auquel le laptop doit accéder, tandis que votre desktop possède sa propre clé. La révocation reste ainsi simple : si vous perdez un appareil, il suffit de supprimer une ligne identifiable sur chaque serveur, et les autres appareils continuent de fonctionner.

Quelles permissions appliquer au répertoire .ssh et à authorized_keys ?

Définissez 700 sur ~/.ssh, ainsi que 600 sur authorized_keys et sur chaque clé privée. Ces fichiers doivent appartenir au compte qui les utilise. sshd s’exécute par défaut avec StrictModes yes. Un fichier ou un répertoire personnel accessible en écriture à un autre utilisateur que vous lui fait ignorer silencieusement votre clé. La seule trace est alors Authentication refused: bad ownership or modes dans le journal d’authentification ou le journal systemd du serveur.

Comment supprimer une clé SSH d’un serveur ?

Supprimez la ligne de la clé dans ~/.ssh/authorized_keys, pour le compte auquel elle était autorisée. Repérez la bonne ligne grâce à son commentaire, c’est-à-dire le libellé situé après le matériau de la clé. Les nouvelles connexions avec cette clé échouent immédiatement, mais les sessions déjà ouvertes restent actives. Si l’appareil a été volé, fermez également toute session active correspondante. Répétez l’opération sur chaque serveur où la clé a été copiée.

Dois-je protéger ma clé SSH par une passphrase ?

Pour une clé stockée sur un laptop ou un desktop, oui. La passphrase chiffre le fichier de clé. Une copie volée ou divulguée est donc inutilisable seule, et ssh-agent permet de la saisir une fois par session plutôt qu’à chaque connexion. Les clés utilisées par une automatisation sans surveillance sur un serveur n’ont généralement pas de passphrase, car personne n’est présent pour la saisir. Protégez-les en limitant les actions que le compte cible peut effectuer.