Les certificats OpenSSH permettent de remplacer la gestion fastidieuse des clés publiques individuelles par une autorité de certification (CA) qui signe les identités utilisateur et hôte.
Avantages : rotation facilitée, révocation centralisée, politiques sur la durée de validité et les autorisations.
Plan de l’article
- Concepts : clé de CA, certificats utilisateur/hôte, Principals, Validité
- Créer une CA OpenSSH
- Signer des clés utilisateur
- Signer des clés hôte
- Déployer la confiance (TrustedUserCAKeys / @cert-authority)
- Révoquer/faire tourner les certificats
- Bonnes pratiques
Concepts clés
- CA (Certificate Authority) : une paire de clés (privée/publique) qui signe les clés.
- Certificat utilisateur : associe une clé publique à un ou plusieurs principals (comptes autorisés) + options (force-command, permit-pty, etc.).
- Certificat hôte : évite l’avertissement host key verification en prouvant l’identité du serveur.
- Validité : dates
valid-afteretvalid-beforelimitent la fenêtre d’usage.
Créer une CA OpenSSH
Générer la clé de CA (à garder offline si possible) :
ssh-keygen -t ed25519 -f /etc/ssh/ssh_ca -C "OpenSSH CA"
chmod 600 /etc/ssh/ssh_ca
Exporter la clé publique de la CA :
cat /etc/ssh/ssh_ca.pub
Signer une clé utilisateur
- L’utilisateur possède déjà une clé (
~/.ssh/id_ed25519.pub). - La CA signe cette clé pour le principal
alice(valide 24h) :
ssh-keygen -s /etc/ssh/ssh_ca -I alice-20251014 -n alice -V +24h ~/.ssh/id_ed25519.pub
Le certificat généré ~/.ssh/id_ed25519-cert.pub est présenté au serveur lors de l’authentification.
Signer une clé hôte
Sur le serveur, signer la clé hôte (ici ed25519) :
ssh-keygen -s /etc/ssh/ssh_ca -I host-web-01 -h -n web-01.exemple.com -V +52w /etc/ssh/ssh_host_ed25519_key.pub
Déclarez la confiance côté client dans ~/.ssh/known_hosts (ou global /etc/ssh/ssh_known_hosts) :
@cert-authority *.exemple.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...clePublicDeLaCA...
Déployer la confiance côté serveur
Dans /etc/ssh/sshd_config, indiquer que le serveur fait confiance à la CA utilisateur :
TrustedUserCAKeys /etc/ssh/ssh_ca_users.pub
PubkeyAuthentication yes
PasswordAuthentication no
Puis recharger :
sudo systemctl reload sshd
Révocation et rotation
- Durée courte (ex. 24h/7j) pour limiter l’impact d’une fuite.
- Listes de révocation via
RevokedKeyssi une clé est compromise. - Renouvellement automatisé (cron/CI) avec suivi d’audits.
Bonnes pratiques
- Stocker la clé privée de CA dans un coffre (HSM/HashiCorp Vault) ou offline.
- Séparer CA utilisateurs et CA hôtes.
- Restreindre les options (
no-agent-forwarding,no-port-forwarding,force-command) selon le rôle. - Journaliser les signatures et surveiller la dérive des certificats.
Conclusion
Avec une CA OpenSSH, vous simplifiez la gestion des accès : on signe, on révoque, on fait tourner.
Les certificats SSH apportent scalabilité, sécurité et traçabilité aux environnements d’administration modernes.


