Clés SSH : ajouter un deuxième accès à son serveur sans se verrouiller dehors

Le cas est vécu. Un serveur loué chez un hébergeur, une quinzaine de services en production, et une clé d’accès unique posée sur le poste de l’atelier. Ce poste était devenu, sans que personne ne l’ait décidé, le point de défaillance unique de toute l’infrastructure.

Sommaire

1. Ce qu’est une clé SSH, en deux minutes
2. Créer une deuxième clé sur un autre poste
3. Installer la clé publique sur le serveur
4. La règle d’or : garder une session ouverte
5. Phrase de passe : le vrai arbitrage
6. Le ménage : clés orphelines et fichier encombré
7. Ce qu’il faut écrire quelque part

1. Ce qu’est une clé SSH, en deux minutes

Une clé SSH est une paire de fichiers qui vont ensemble. La clé privée reste sur le poste et ne le quitte jamais. La clé publique, elle, est destinée à être copiée sur les serveurs auxquels on veut accéder.

Au moment de la connexion, le serveur pose une question que seule la clé privée sait résoudre. Aucun mot de passe ne circule. C’est plus sûr qu’un mot de passe, et c’est aussi pour cette raison que la connexion se fait ensuite sans rien taper : le serveur a déjà la preuve qu’il avait besoin.

Conséquence directe : perdre la clé privée, c’est perdre l’accès. La copier sur une clé USB qui traîne, c’est offrir l’accès. Tout tient dans ce fichier.

2. Créer une deuxième clé SSH sur un autre poste

Le réflexe naturel serait de copier la clé existante d’une machine à l’autre. C’est une mauvaise idée : une clé privée qui voyage est une clé privée exposée, et si elle doit un jour être révoquée, il faudra la révoquer partout.

La bonne pratique est une clé par poste. Sur le second poste, celui qu’on veut ajouter :

ssh-keygen -t ed25519 -C "poste-bureau" -f ~/.ssh/srv01_acces

Le commentaire après -C n’a aucun effet technique, mais il apparaîtra plus tard dans le fichier du serveur. Dans six mois, c’est lui qui permettra de savoir à quelle machine correspond cette clé. Un nom explicite évite bien des hésitations.

Deux fichiers apparaissent :
srv01_acces (la privée, à ne jamais partager) et
srv01_acces.pub (la publique, celle qu’on va transmettre).

3. Installer la clé publique sur le serveur

Afficher la clé publique sur le second poste :

cat ~/.ssh/srv01_acces.pub

La sortie tient sur une seule ligne, qui commence par ssh-ed25519 et se termine par le commentaire choisi. C’est cette ligne entière qu’il faut copier.

Ensuite, depuis la session déjà ouverte sur le serveur (celle qui fonctionne, ouverte depuis le poste d’origine), ajouter la ligne au fichier des clés autorisées :

echo "ssh-ed25519 AAAA... poste-bureau" >> ~/.ssh/authorized_keys

Le double chevron est capital. Un seul chevron écraserait le fichier et supprimerait la clé existante, ce qui reviendrait à se couper l’accès en une frappe. C’est l’erreur classique, et elle est irréversible sans console de secours.

4. La règle d’or : garder une session ouverte

Tant que le nouvel accès n’est pas vérifié, la session en cours ne se ferme pas. Elle est le filet.

Depuis le second poste, dans une autre fenêtre :

ssh -i ~/.ssh/srv01_acces -p 2222 utilisateur@203.0.113.10

L’option -i désigne la clé à présenter. Sans elle, le client tente ses clés par défaut, échoue, et affiche un refus qui laisse croire à un problème de serveur alors que rien n’est cassé. Le port n’est à préciser que si le serveur n’écoute pas sur le port standard, ce qui est une bonne habitude par ailleurs.

Si la connexion aboutit, l’ancienne session peut être refermée. Si elle échoue, la session de secours est toujours là pour corriger le tir.

Pour éviter de retaper cette longue commande, quelques lignes dans ~/.ssh/config sur le second poste suffisent :

Host srv01
    HostName 203.0.113.10
    Port 2222
    User utilisateur
    IdentityFile ~/.ssh/srv01_acces

La connexion se résume alors à ssh srv01. Ce fichier a un mérite supplémentaire : il documente la configuration à l’endroit où on la cherchera.

5. Phrase de passe : le vrai arbitrage

Au moment de la création, la commande propose une phrase de passe. La laisser vide donne une clé utilisable immédiatement, sans rien à taper. C’est confortable, et c’est aussi un choix de sécurité qu’il faut faire en connaissance de cause.

Sans phrase de passe, la clé privée est en clair sur le disque. Toute personne qui obtient le fichier obtient l’accès au serveur : vol du portable, sauvegarde du dossier personnel qui traîne, poste laissé déverrouillé. La clé ne protège plus rien par elle-même, elle ne fait que déplacer la protection vers la sécurité physique de la machine.

Sur un poste fixe, dans un local fermé, l’absence de phrase de passe se défend. Sur un portable qui sort de la maison, beaucoup moins. Une phrase de passe peut d’ailleurs être ajoutée après coup, sans recréer la clé :

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

L’agent SSH la garde ensuite en mémoire pour la durée de la session, ce qui évite de la ressaisir à chaque connexion.

6. Le ménage : clés orphelines et fichier encombré

Au fil des années, le fichier authorized_keys accumule des lignes dont plus personne ne connaît l’origine. Une machine réinstallée, un prestataire de passage, un essai jamais nettoyé. Chacune de ces lignes est un accès permanent au serveur.

Pour les inventorier :

ssh-keygen -lf ~/.ssh/authorized_keys

La commande affiche l’empreinte et le commentaire de chaque clé. Toute ligne dont la moitié privée n’est identifiée sur aucune machine connue est une clé orpheline, et sa place n’est pas là.

Deux précautions avant de supprimer quoi que ce soit : sauvegarder le fichier (cp authorized_keys authorized_keys.sauvegarde), et garder une session ouverte pendant l’opération. Une erreur sur ce fichier se paie comptant.

7. Ce qu’il faut écrire quelque part

Le dispositif décrit ici ne vaut que si l’on sait s’en servir le jour où c’est nécessaire, souvent des mois plus tard, et rarement dans de bonnes conditions. Quatre informations méritent d’être consignées ailleurs que dans la mémoire : quelles machines détiennent une clé pour ce serveur, sous quel nom de fichier, quel compte et quel port utiliser, et où se trouve la sauvegarde du fichier des clés autorisées.

Ce document n’a pas à contenir la moindre clé privée ni le moindre mot de passe. Il n’a besoin de dire que où chercher. C’est précisément ce qui manque le plus souvent quand la panne survient.

Conclusion

Un serveur accessible depuis une seule machine n’est pas un serveur sécurisé, c’est un serveur fragile. La différence entre les deux se découvre en général au plus mauvais moment. Créer une seconde clé prend cinq minutes, ne coûte rien, et supprime un point de défaillance unique.

Deux réflexes résument tout : ne jamais fermer la session qui fonctionne avant d’avoir vérifié la nouvelle, et ne jamais faire voyager une clé privée d’une machine à l’autre.

Responsabilité. Les commandes présentées ici ont été utilisées avec succès sur des systèmes Linux courants, mais chaque configuration a ses particularités (droits sur le dossier, politique du serveur SSH, restrictions de l’hébergeur). Elles sont fournies à titre informatif et leur mise en oeuvre reste sous la responsabilité de la personne qui les exécute. Créer une deuxième clé SSH prend cinq minutes, ne coûte rien, et supprime un point de défaillance unique.

À propos

Les adresses, ports et noms de fichiers utilisés dans cet article sont fictifs et destinés à l’exemple. L’adresse 203.0.113.10 appartient à une plage réservée à la documentation et ne correspond à aucune machine réelle.

Article rédigé en août 2026, à partir d’une situation rencontrée sur une infrastructure personnelle. Les commandes ont été vérifiées sur OpenSSH 9.x.

Rédaction et mise en forme assistées par Claude (Anthropic). Relecture et validation technique : MD.

MD