TL;DR — Résumé Rapide

Guide de gestion des clés SSH pour sysadmins: générez des clés Ed25519, utilisez ssh-agent, configurez ~/.ssh/config et utilisez des certificats SSH.

Les clés SSH sont le fondement de l’accès distant sécurisé pour tout sysadmin et professionnel DevOps. Ce guide de gestion des clés SSH couvre le cycle de vie complet: générer des clés, les mettre en cache avec ssh-agent, organiser plusieurs hôtes avec ~/.ssh/config, déployer des clés publiques, faire la rotation et révoquer les credentials compromis, passer à l’échelle avec des certificats SSH et renforcer la sécurité avec des clés matérielles.

Prérequis

  • Linux, macOS ou WSL avec le client OpenSSH (ssh, ssh-keygen, ssh-agent, ssh-copy-id).
  • Accès SSH à au moins un serveur distant pour s’exercer.
  • Optionnel: ssh-audit (pip install ssh-audit) pour l’audit des algorithmes.
  • Optionnel: YubiKey ou autre clé matérielle FIDO2 pour une protection maximale.

Génération de Clés SSH: Ed25519 vs RSA

Ed25519 (recommandé)

ssh-keygen -t ed25519 -C "vous@exemple.com"

Ed25519 utilise la cryptographie sur courbe elliptique Curve25519. Les clés font 256 bits, les signatures sont rapides et l’algorithme est résistant aux attaques par canal auxiliaire. C’est le choix par défaut pour toutes les nouvelles clés.

RSA (compatibilité héritée)

ssh-keygen -t rsa -b 4096 -C "vous@exemple.com"

Utilisez RSA-4096 uniquement lorsque le système distant ne supporte pas Ed25519 — par exemple, de très anciennes versions d’OpenSSH (< 6.5) ou certains équipements réseau. RSA-2048 n’est plus recommandé.

Meilleures pratiques pour les phrases secrètes

  • Définissez toujours une phrase secrète. Elle chiffre votre clé privée sur le disque. Une clé volée sans la phrase secrète est inutile.
  • Utilisez au moins 20 caractères — une phrase aléatoire générée par votre gestionnaire de mots de passe est idéale.
  • Stockez-la dans votre gestionnaire de mots de passe (1Password, Bitwarden, pass).

SSH Agent: Mise en Cache des Clés pour la Session

# Démarrer l'agent
eval "$(ssh-agent -s)"

# Ajouter votre clé (demande la phrase secrète une fois)
ssh-add ~/.ssh/id_ed25519

# Lister les clés chargées
ssh-add -l

# Supprimer toutes les clés
ssh-add -D

Conseil de sécurité: Passez -t 3600 à ssh-add pour expirer automatiquement la clé après une heure:

ssh-add -t 3600 ~/.ssh/id_ed25519

Fichier de Configuration SSH: Gestion de Plusieurs Hôtes

# ~/.ssh/config

# Paramètres par défaut pour tous les hôtes
Host *
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3

# Serveur web de production
Host prod-web
    HostName 203.0.113.10
    User deploy
    Port 22
    IdentityFile ~/.ssh/id_ed25519_prod

# Serveur de base de données interne via jump host
Host db-internal
    HostName 10.0.1.50
    User dbadmin
    ProxyJump prod-web

# GitHub
Host github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_github

Avec cette configuration, ssh prod-web se connecte avec le bon utilisateur et la bonne clé, et ssh db-internal tunnelise automatiquement via le bastion.

Déploiement des Clés Publiques

ssh-copy-id (le plus simple)

ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@hote

Déploiement manuel

cat ~/.ssh/id_ed25519.pub | ssh utilisateur@hote \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
   cat >> ~/.ssh/authorized_keys && \
   chmod 600 ~/.ssh/authorized_keys"

Permissions de fichiers — critique

CheminPermissionPourquoi
~/.ssh/700Seul le propriétaire peut lister/entrer
~/.ssh/id_ed25519600Clé privée — lecture/écriture propriétaire uniquement
~/.ssh/id_ed25519.pub644Clé publique — lisible par tous
~/.ssh/authorized_keys600Seul le propriétaire peut modifier
~/.ssh/config600Empêche les autres de lire votre configuration

SSH refusera d’utiliser des clés avec des permissions lisibles par tous et échouera silencieusement.

Stratégies de Rotation des Clés

Faites la rotation des clés SSH lorsque:

  • Une clé est plus ancienne que la politique de votre organisation (généralement 1–2 ans).
  • Un employé ayant accès aux clés quitte l’entreprise.
  • Une machine ou un support contenant la clé privée est mis hors service ou perdu.
  • Vous suspectez une compromission.

Procédure de rotation sécurisée:

  1. Générez une nouvelle paire de clés: ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_nouvelle.
  2. Déployez la nouvelle clé publique sur tous les hôtes sans supprimer l’ancienne.
  3. Vérifiez que vous pouvez vous connecter avec la nouvelle clé: ssh -i ~/.ssh/id_ed25519_nouvelle utilisateur@hote.
  4. Mettez à jour ~/.ssh/config pour utiliser la nouvelle clé.
  5. Supprimez l’ancienne clé publique de tous les fichiers authorized_keys.
  6. Supprimez de façon sécurisée l’ancienne clé privée: shred -u ~/.ssh/id_ed25519_ancienne.

Révocation des Clés Compromises

SSH n’a pas de liste de révocation intégrée pour les clés publiques, la révocation est donc un processus manuel:

  1. Supprimez la clé immédiatement de tous les fichiers authorized_keys sur tous les hôtes.
  2. Pour les infrastructures de certificats SSH, ajoutez la clé à un fichier RevokedKeys sur le serveur (RevokedKeys /etc/ssh/revoked_keys dans sshd_config).
  3. Auditez les journaux de connexion (/var/log/auth.log, journalctl -u ssh) pour les sessions utilisant la clé compromise.
  4. Faites la rotation de tout secret ou credential qui pourrait avoir été accédé.

Certificats SSH: Gestion de Flottes à Grande Échelle

Lorsque vous avez des dizaines ou des centaines de serveurs, gérer authorized_keys sur chaque machine est source d’erreurs. Les certificats SSH résolvent ce problème en introduisant une Autorité de Certification (CA).

Créer une paire de clés CA

ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "org-ssh-ca"

Gardez ca_key privée et hors ligne. Distribuez ca_key.pub à chaque serveur.

Configurer les serveurs pour faire confiance à la CA

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub

Signer une clé d’utilisateur

ssh-keygen -s /etc/ssh/ca_key \
  -I "alice@corp" \
  -n alice,admin \
  -V +30d \
  ~/.ssh/id_ed25519.pub

Avantages par rapport à authorized_keys

  • Expiration automatique — les certificats expirent sans nettoyage manuel.
  • Contrôle centralisé — révoquez en supprimant la confiance CA ou en utilisant RevokedKeys.
  • Application des principals — un certificat ne peut se connecter qu’avec des noms d’utilisateur spécifiques.

Clés Matérielles: YubiKey et FIDO2

# Générer une clé stockée sur YubiKey/FIDO2 (OpenSSH 8.2+)
ssh-keygen -t ed25519-sk -O resident -C "yubikey@corp"

La clé privée ne quitte jamais le dispositif. Lors de l’authentification, le dispositif nécessite un contact physique, rendant impossible le vol à distance des clés.

Tableau Comparatif: Ed25519 vs RSA vs ECDSA

CaractéristiqueEd25519RSA-4096ECDSA P-256
Taille de clé256 bits4096 bits256 bits
Vitesse de signatureTrès rapideLenteRapide
Vitesse de vérificationRapideRapideRapide
Taille du fichier de clé~400 octets~3.3 Ko~600 octets
Compatibilité héritéeOpenSSH 6.5+ (2014)UniverselleOpenSSH 5.7+ (2011)
Résistance aux attaques par canal auxiliaireExcellenteModéréeFaible
Clé FIDO2/matérielleOui (ed25519-sk)NonOui (ecdsa-sk)
RecommandationPremier choixHéritage seulementÀ éviter

Scénario Réel

Vous avez une flotte de production de 40 serveurs Linux. Trois développeurs ont quitté l’entreprise le mois dernier. Vous devez révoquer immédiatement leur accès SSH sans interruption de service.

Avec authorized_keys: Vous devez accéder (ou utiliser Ansible) sur les 40 serveurs, trouver l’empreinte de clé publique de chaque utilisateur partant, supprimer ces lignes et répéter. Un serveur oublié est une faille.

Avec des certificats SSH: La CA cesse simplement de signer des certificats pour ces utilisateurs. Les certificats existants expirent naturellement. Pour une révocation immédiate, ajoutez leurs empreintes au fichier RevokedKeys déployé via Ansible en quelques secondes:

ssh-keygen -lf utilisateur-partant-cert.pub >> /tmp/révoqués
ansible all -m copy -a "src=/tmp/révoqués dest=/etc/ssh/revoked_keys mode=0644"
ansible all -m service -a "name=sshd state=reloaded"

Terminé en moins de deux minutes sur toute la flotte.

Configuration SSH sur GitHub et GitLab

GitHub

gh ssh-key add ~/.ssh/id_ed25519.pub --title "poste-travail-2026"

Test: ssh -T git@github.com

GitLab

Ajoutez la clé dans GitLab → Paramètres utilisateur → Clés SSH.

Test: ssh -T git@gitlab.com

Pièges et Cas Limites

  • StrictHostKeyChecking=no dans les scripts — Désactiver la vérification de la clé d’hôte supprime la protection contre les attaques man-in-the-middle. Pré-remplissez plutôt ~/.ssh/known_hosts avec ssh-keyscan lors du provisionnement.
  • Clés partagées — Ne partagez jamais une clé privée entre plusieurs personnes ou machines. Chaque personne et machine doit avoir sa propre paire de clés.
  • Connexion root — Désactivez PermitRootLogin yes dans sshd_config. Utilisez un utilisateur normal avec sudo.
  • Noms de clés non standard — Si vous créez une clé avec un nom non standard, SSH ne l’utilisera pas automatiquement. Spécifiez-la dans ~/.ssh/config ou passez -i explicitement.

Dépannage

ProblèmeSolution
”Permission denied (publickey)“Vérifiez les permissions avec ls -la ~/.ssh/. Exécutez ssh -vvv hote pour voir quelles clés sont essayées
L’agent ne fonctionne pasVérifiez avec ssh-add -l. Si “Could not open connection to agent”, exécutez eval $(ssh-agent -s)
Mauvaise clé utilisée pour l’hôteAjoutez IdentityFile explicite et IdentitiesOnly yes dans ~/.ssh/config
”Host key verification failed”La clé du serveur a changé. Supprimez l’ancienne entrée: ssh-keygen -R hostname
Certificat rejetéVérifiez l’expiration avec ssh-keygen -L -f cert.pub. Vérifiez que le principal correspond au nom d’utilisateur
YubiKey non détectéAssurez-vous que pcscd est actif (systemctl start pcscd). Essayez ssh-add -K pour charger les clés résidentes

Résumé

  • Générez des clés Ed25519 pour toutes les nouvelles paires; utilisez RSA-4096 uniquement pour la compatibilité héritée.
  • Définissez toujours une phrase secrète et utilisez ssh-agent pour la mettre en cache pour la session.
  • Utilisez ~/.ssh/config avec ProxyJump pour gérer proprement plusieurs hôtes et bastions.
  • Déployez les clés avec ssh-copy-id; ne partagez jamais les clés privées entre personnes ou machines.
  • Pour les flottes de plus de ~10 serveurs, adoptez les certificats SSH pour l’expiration, les principals et la révocation centralisée.
  • Stockez les clés sur matériel FIDO2 (YubiKey) pour une sécurité maximale.
  • Appliquez les permissions de fichiers correctes (700 sur ~/.ssh/, 600 sur les clés et authorized_keys).
  • Auditez régulièrement votre configuration de serveur SSH avec ssh-audit.

Articles Connexes