06 - Gerer ses clés : rotation, backup et hardware keys

Ce que tu vas apprendre

• Quand et comment faire une rotation de clés
• Les stratégies de sauvegarde qui marchent
• Pourquoi une passphrase est non-negociable
• Les clés materielles (YubiKey, SoloKeys)
• Quoi faire quand une clé est compromise

Prerequisites

• 02 - Les clés SSH : génération et configuration
• 03 - GPG : clés GPG et leur gestion

Mon principe : une clé par machine, jamais de partage

Avant de parler de rotation et de backup, voici ma regle numero un : une clé privee ne quitte jamais la machine ou elle a ete générée. Si tu as un laptop perso, un laptop pro et un serveur de dev, tu as trois clés SSH différentes. Pas une clé copiee trois fois.

Pourquoi ? Parce que si ta clé pro est compromise (laptop vole, disque non chiffre), tes serveurs perso ne sont pas affectes. Tu revoques une clé, pas trois. Le surcout est minime : copier une clé publique supplementaire dans authorized_keys prend 10 secondes.

Passphrases : toujours, sans exception

Je l'ai deja dit dans l'article sur SSH, je le répété. Une clé SSH ou GPG sans passphrase, c'est un fichier texte qui donne acces a tes serveurs. Ton disque dur est vole ? Ton backup fuite ? Un malware copie ~/.ssh/ ? Sans passphrase, l'attaquant a acces immédiatement.

Avec une passphrase, la clé est chiffree avec AES-256. L'attaquant a un fichier inutile sans le mot de passe.

bash# Ajouter ou changer la passphrase d'une cle existante
ssh-keygen -p -f ~/.ssh/id_ed25519

Pour la passphrase elle-meme : au moins 20 caractères, melange de mots. Quelque chose comme correcte-batterie-cheval-agrafe (référencé a XKCD 936). Pas un mot de passe classique de 8 caractères avec des symboles.

Rotation de clés : quand et comment

La rotation, c'est remplacer une clé par une nouvelle. Quand le faire :

• Regularite : tous les 12 a 24 mois. C'est une bonne habitude meme sans incident.
• Changement de machine : nouveau laptop = nouvelle clé.
• Depart d'un projet/entreprise : régénéré tes clés pro.
• Suspicion de compromission : la, c'est immediat.

La procedure (pour SSH) :

bash# 1. Generer la nouvelle cle
ssh-keygen -t ed25519 -C "email@exemple.com" -f ~/.ssh/id_ed25519_nouveau

# 2. Ajouter la nouvelle cle sur tous les serveurs/services
ssh-copy-id -i ~/.ssh/id_ed25519_nouveau.pub user@serveur

# 3. Tester que la nouvelle cle fonctionne
ssh -i ~/.ssh/id_ed25519_nouveau user@serveur

# 4. Mettre a jour ~/.ssh/config
# 5. Supprimer l'ancienne cle des authorized_keys sur les serveurs
# 6. Supprimer l'ancienne cle locale

L'étape 5 est celle qu'on oublie toujours. L'ancienne clé traine dans authorized_keys pendant des annees. Fais-le. Maintenant.

Pour GPG, la rotation est plus complexe. Si ta clé a une date d'expiration (ce que je recommande, 2 ans), tu peux soit prolonger la validite, soit créer une nouvelle clé et publier un certificat de revocation pour l'ancienne :

bash# Prolonger une cle GPG
gpg --edit-key 1234ABCD5678EF90
gpg> expire
# Suivre les instructions

# Revoquer une cle
gpg --gen-revoke 1234ABCD5678EF90 > revocation.asc
gpg --import revocation.asc
gpg --keyserver keys.openpgp.org --send-keys 1234ABCD5678EF90

Backup : le sujet que tout le monde repousse

Perdre sa clé privee GPG, c'est perdre acces a tous les fichiers chiffres avec. Pas de recovery possible. C'est définitif.

Ma stratégie de backup (pour les clés GPG, les clés SSH sont plus faciles a régénérer) :

Option 1 : clé USB chiffree. Exporte ta clé privee GPG sur une clé USB, chiffre la clé USB avec LUKS (Linux) ou BitLocker (Windows). Stocke-la dans un endroit physique différent de ta machine principale. Un tiroir chez tes parents, un coffre a la banque.

bash# Exporter la cle privee GPG
gpg --armor --export-secret-keys 1234ABCD5678EF90 > cle_privee_gpg.asc

# Copier sur la cle USB (deja montee et chiffree)
cp cle_privee_gpg.asc /mnt/usb_chiffree/

# Effacer la copie locale
shred -u cle_privee_gpg.asc

Option 2 : paperkey. Pour les plus paranoiaques. paperkey extrait la partie secrete d'une clé GPG et la convertit en format imprimable. Tu imprimes ca sur du papier, tu le ranges.

bashgpg --export-secret-keys 1234ABCD5678EF90 | paperkey --output cle_papier.txt

Ca fait un peu excessif ? Peut-etre. Mais si ta maison brûlé et que ta clé USB fond avec, le papier dans un coffre a la banque te sauve.

Pour les clés SSH : pas besoin de backup aussi rigoureux. Tu peux toujours régénérer une clé SSH et l'ajouter sur tes serveurs. Le seul risque, c'est de ne plus pouvoir acceder au serveur pour ajouter la nouvelle clé (hello, vendredi soir). Solution : acces console chez ton hébergeur, ou une deuxieme clé de secours deja en place.

Cles materielles : YubiKey et compagnie

Une clé materielle (hardware security key) est un petit dispositif USB qui stocke ta clé privee dans une puce sécurisée. La clé privee ne sort jamais du device. Meme si ton ordinateur est compromis par un malware, l'attaquant ne peut pas copier la clé.

Les modèles courants :

• YubiKey 5 (Yubico, environ 55 euros) : la référencé. Supporte FIDO2, GPG, PIV, TOTP. USB-A, USB-C ou NFC selon le modèle.
• SoloKeys Solo 2 (environ 35 euros) : open source. Supporte FIDO2. Moins de fonctionnalités que la YubiKey, mais le hardware et le firmware sont auditable.

Pour SSH avec une YubiKey :

bash# Generer une cle SSH residente sur la YubiKey (FIDO2)
ssh-keygen -t ed25519-sk -O resident -O application=ssh:perso

# La cle privee est sur la YubiKey, seule la "cle handle" est sur le disque

Le -sk signifie "security key". A chaque connexion SSH, tu dois toucher physiquement la YubiKey. Un malware ne peut pas se connecter a ta place pendant que tu dors.

Pour GPG sur YubiKey, c'est un peu plus complexe. Tu transferes tes sous-clés GPG sur la YubiKey :

bashgpg --edit-key 1234ABCD5678EF90
gpg> keytocard
# Transferer la cle de signature, puis la cle de chiffrement

Mon avis : si tu travailles sur des projets sensibles ou si tu veux la meilleure sécurité possible, une YubiKey est un excellent investissement. 55 euros pour dormir tranquille. En acheter deux (une principale, une de backup) est encore mieux.

Que faire quand une clé est compromise

Ca arrive. Laptop vole, clé privee copiee, fuite. Voici le protocole :

1. Ne pas paniquer, mais agir vite. Dans les minutes, pas les jours.
2. Revoquer la clé SSH : la retirer de tous les authorized_keys, GitHub, GitLab. Changer les clés de déploiement dans le CI/CD.
3. Revoquer la clé GPG : importer le certificat de revocation, le publier sur les keyservers.
4. Generer de nouvelles clés sur une machine propre.
5. Auditer les acces : vérifier les logs SSH des serveurs, les commits git recents, les actions dans le CI.
6. Communiquer : prevenir ton équipe, tes admins système.

C'est aussi pour ca qu'il faut une clé par machine : la surface d'impact est réduite.

Checklist des bonnes pratiques

• Passphrase sur toutes les clés (SSH et GPG)
• Une clé par machine
• Rotation tous les 12-24 mois
• Backup de la clé GPG privee (USB chiffree ou paperkey)
• Certificat de revocation GPG généré des la création de la clé
• Désactiver l'authentification par mot de passe SSH sur les serveurs
• Chiffrement du disque sur toutes tes machines (FileVault, LUKS, BitLocker)

Le dernier point est souvent oublie. Meme avec une passphrase sur ta clé, un disque non chiffre expose tout le reste : tokens, cookies, historique, clé de l'agent SSH en mémoire...

Prochain et dernier article : le glossaire complet de tous les termes de cette serie.

Navigation : Precedent : 05 - TLS et certificats | Suivant : 07 - Glossaire

Sources

• YubiKey Documentation par Yubico
• FIDO2/WebAuthn with OpenSSH par OpenSSH
• ArchWiki - GnuPG Backup par ArchWiki
• Paperkey - an OpenPGP key archiver par David Shaw

Retrouve d'autres articles techniques sur paltemps.fr.