Quand on se lance dans le self-hosting, on finit toujours par taper la même commande : ssh-keygen, Entrée trois fois, et hop… ça marche. Sauf que tes clés SSH ne sont pas un détail : ce sont littéralement les clés d’accès à tes serveurs. Et si tu les fabriques ou les organises mal, tu passes très vite de « un fichier volé » à « un accès permanent à tout ton parc ».
Dans ce guide, je te donne la méthode que j’applique sur mon homelab : bon format, bonne commande, passphrase obligatoire, organisation par usages, et ssh-agent bien configuré. Pas de théorie inutile : juste des décisions concrètes qui réduisent le risque.
1) Le bon format en 2026 : Ed25519, point
Si tu ne dois retenir qu’une chose : génère tes clés en Ed25519. La commande minimale est :
ssh-keygen -t ed25519Pourquoi je pousse Ed25519 ? Parce que c’est un choix moderne, efficace et robuste dans l’écosystème OpenSSH. Et surtout : c’est le format que tu veux standardiser dans ton homelab, pour éviter les exceptions et les “ça marche chez moi” qui finissent par coûter cher.
Ce que tu évites
- DSA : obsolète, à oublier.
- ECDSA : acceptable en théorie, mais je préfère éviter les compromis et rester sur Ed25519.
- RSA : utile uniquement pour l’interop avec un vieux système. Sinon, tu perds du temps à gérer un héritage.
2) La commande idéale, décortiquée
Voici la ligne que j’utilise et que je te recommande d’adopter comme standard :
ssh-keygen -t ed25519 -a 100 -C "moi@mon-pc" -f ~/.ssh/id_ed25519_mon_pcChaque option a un rôle. Et c’est précisément là que beaucoup de gens “génèrent n’importe comment” : ils laissent des valeurs par défaut sans comprendre ce qu’elles protègent.
-t ed25519 : le type de clé
On l’a vu : c’est ton standard. Pas de débat.
-a 100 : le blindage du fichier au repos
Ta clé privée n’est pas stockée en clair si tu mets une passphrase. Elle est chiffrée, et -a règle le coût de dérivation de la clé de chiffrement (KDF). Plus tu augmentes ce coût, plus un attaquant qui vole le fichier doit “payer” du temps pour tester des passphrases.
En pratique, 100 est un bon compromis : tu ne le sens presque pas à l’usage (une fois au déverrouillage), mais tu rends les essais beaucoup plus coûteux pour un attaquant.
Point important : -a ne sert à rien si tu ne mets pas de passphrase. Donc on enchaîne.
-C : un commentaire utile
Le commentaire (moi@mon-pc) n’ajoute pas de sécurité cryptographique. Mais il te sauve la vie quand tu retrouves une clé dans un authorized_keys six mois plus tard : tu sais à quoi elle correspond.
-f : le nom explicite qui évite le chaos
Le chemin de sortie (~/.ssh/id_ed25519_mon_pc) n’est pas qu’un détail. C’est l’organisation qui te permet de savoir quelle clé est où, et de révoquer vite quand une machine change.
Ce que je ne fais jamais : -N
Je ne passe jamais la passphrase en argument avec -N. Elle finirait dans l’historique de ton shell ou dans des logs. Tu la tapes au prompt, c’est plus sûr.
3) Passphrase obligatoire (et comment ne pas la rendre pénible)
Une clé SSH sans passphrase, c’est une clé privée qui peut ouvrir tes serveurs et qui traîne sur ton disque. Si un jour ta machine est compromise, la “sécurité au repos” disparaît.
Ma règle : toujours une passphrase forte. Et ensuite, on gère le confort avec ssh-agent.
4) Le piège : une clé SSH n’expire jamais
Contrairement à un certificat TLS, une paire de clés SSH “classique” n’a pas de date de validité. Une fois que ta clé publique est dans authorized_keys, elle fonctionne indéfiniment jusqu’à ce que tu la retires.
Le vrai danger en homelab, ce n’est pas “la clé trop vieille”. C’est la clé oubliée : un ancien laptop revendu, une VM réinstallée, un téléphone perdu… et pourtant l’accès reste valide parce que personne n’a fait le ménage.
Deux solutions réalistes
- Rotation manuelle : tu régénères tes paires périodiquement (par exemple une fois par an) et tu remplaces les clés publiques sur tes serveurs.
- Certificats SSH : tu utilises une CA et des certificats avec une fenêtre de validité. Quand ça expire, le serveur refuse automatiquement.
Mon avis : pour un petit parc (un VPS + un NAS), monter une PKI complète peut être disproportionné. Mais dès que tu passes à plusieurs machines, l’approche certificats devient intéressante. Dans tous les cas, garde en tête une règle : audit régulier de qui a accès à quoi.
5) Combien de clés ? et combien de passphrases ?
On confond souvent deux décisions différentes : le nombre de clés et le nombre de passphrases. Elles ne répondent pas aux mêmes objectifs.
“Une clé par usage” ≠ “une clé par serveur”
Le bon découpage, ce n’est pas la destination (VPS, NAS, etc.). C’est le point de départ : quelle machine cliente et quel contexte.
Exemple de découpage sain :
PC → id_ed25519_pc (ouvre VPS, NAS, etc.)
Laptop → id_ed25519_laptop (ouvre VPS, NAS, etc.)
PC → id_ed25519_github (dédiée aux services tiers)Pourquoi une clé dédiée pour GitHub / services tiers ? Parce que tu confies la clé publique à un tiers. Autant qu’elle ne soit pas réutilisée pour tes accès “maison”.
Une passphrase par machine (pas par clé)
La passphrase sert à protéger un fichier de clé privée volé. Si plusieurs clés vivent sur la même machine et partagent la même passphrase, un attaquant qui accède au disque pourra tenter cette passphrase pour toutes.
Mon conseil pragmatique : une passphrase forte et unique par machine cliente. Toutes les clés générées sur ce poste peuvent partager cette passphrase.
Deux exceptions où tu cloisonnes plus
- Clé tierce (GitHub / services) : passphrase distincte si tu veux renforcer l’isolation.
- Clé matérielle (ex.
ed25519-sk) pour ton accès le plus sensible : la partie secrète ne peut pas être copiée depuis le disque. Là, la passphrase devient presque secondaire, parce que voler le fichier ne suffit plus.
6) ssh-agent : le confort sans sacrifier la sécurité
“Taper une passphrase à chaque connexion, c’est infernal.” Oui. Mais justement : on ne le fait pas. ssh-agent garde tes clés déchiffrées en mémoire le temps de la session.
Le but : tu tapes la passphrase une fois, puis tu enchaînes tes connexions sans friction.
Le réflexe qui change tout : AddKeysToAgent yes
Dans ~/.ssh/config, je mets :
Host *
AddKeysToAgent yes
IdentityFile ~/.ssh/id_ed25519_mon_pcRésultat : à la première utilisation, SSH charge la clé dans l’agent. Ensuite, tu ne retapes pas la passphrase tant que l’agent vit.
Évite les mauvaises surprises : IdentitiesOnly yes
Quand tu as plusieurs clés, SSH peut essayer “trop de choses” et provoquer des refus côté serveur. Pour forcer la clé attendue, je recommande :
Host mon_serveur
HostName ton.ip.ou.domaine
User user_distant
IdentityFile ~/.ssh/id_ed25519_mon_pc
IdentitiesOnly yes7) Bien gérer ssh-agent selon ton OS
Le problème n’est pas ssh-agent. Le problème, c’est le démarrage. Beaucoup de gens lancent ssh-add alors qu’aucun agent ne tourne, ou alors ils démarrent un agent sans appliquer les variables d’environnement.
Windows : l’agent persiste (souvent le plus simple)
Sur Windows, le service OpenSSH agent peut être configuré pour démarrer automatiquement. Ensuite, tu charges tes clés une fois, et elles reviennent après reboot.
Set-Service ssh-agent -StartupType Automatic Start-Service ssh-agentAttention : l’agent garde les clés déchiffrées en mémoire via le service. Si ton accès est critique, la clé matérielle reste la meilleure option.
Linux : keychain ou systemd user
Sur Linux, une approche simple consiste à utiliser keychain pour réutiliser un agent existant et éviter de re-taper la passphrase à chaque session.
sudo apt install keychain
# dans ~/.bashrc :
eval "$(keychain --eval --quiet id_ed25519_pc id_ed25519_github)"Sur certaines configurations desktop, d’autres composants peuvent aussi gérer un agent. L’idée est de garder un contrôle clair sur “qui lance quoi”.
Mode ponctuel : le eval est obligatoire
Pour une tâche isolée, tu peux lancer un agent “jetable” dans ton terminal. Mais fais-le correctement :
eval "$(ssh-agent -s)"Le eval applique les variables d’environnement dans ton shell courant. Sans ça, ton shell ne sait pas où joindre l’agent, et ssh-add échoue.
Arrêter proprement
Si tu as lancé l’agent proprement, tu peux le tuer avec :
ssh-agent -kSi tu as lancé sans eval, tu peux te retrouver avec un agent qui tourne “dans le flou”. Dans ce cas, un nettoyage global peut être nécessaire :
pkill -u "$USER" ssh-agent8) Sécurité ssh-agent : les deux réglages que je fais toujours
ssh-agent est pratique, mais il garde des clés déchiffrées en mémoire. Donc je limite l’exposition.
Timeout sur les clés sensibles
Tu peux demander à l’agent de purger une clé après un délai :
ssh-add -t 8h ~/.ssh/id_ed25519_mon_pcTu peux aussi mettre un comportement par défaut dans la config pour éviter les oublis.
Forwarding d’agent : prudence
Le forwarding d’agent (ForwardAgent yes ou ssh -A) permet au serveur distant d’utiliser ton agent pour rebondir ailleurs. C’est pratique, mais si le serveur est compromis, l’attaquant profite de ton agent tant que tu es connecté.
Je préfère une approche plus maîtrisée : ProxyJump pour le rebond, plutôt que le forwarding d’agent.
Checklist : la méthode à appliquer dès maintenant
- Format : Ed25519 partout.
- Commande :
ssh-keygen -t ed25519 -a 100 -C "..." -f ~/.ssh/nom_explicite. - Passphrase : obligatoire, forte, jamais via
-N. - Nombre de clés : peu. Une par machine cliente, plus une dédiée aux services tiers.
- Passphrases : une par machine (et éventuellement une distincte pour la clé tierce).
- Confort :
AddKeysToAgent yes+IdentitiesOnly yesquand nécessaire. - Rotation / nettoyage : les clés n’expirent pas, donc tu fais un audit et tu révoques vite.
- Accès sensible : clé matérielle si tu veux le cran au-dessus.
Conclusion : reprendre le contrôle de tes accès
Les clés SSH ne sont pas un “détail de configuration”. Ce sont tes serrures. Et une serrure mal gérée, c’est un accès facile à long terme.
Si tu appliques cette méthode—Ed25519, passphrase, organisation claire, ssh-agent propre et audit régulier—tu réduis drastiquement le risque, tout en gardant un homelab fluide. La prochaine étape logique ? Faire l’inventaire de tes authorized_keys et vérifier que chaque clé correspond encore à une machine que tu contrôles.
