OpenSSH Certificates : mettre en place une CA pour signer utilisateurs et hôtes

Publié le 14 décembre 2025

Linux
SSH
Sécurité

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-after et valid-before limitent 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

  1. L’utilisateur possède déjà une clé (~/.ssh/id_ed25519.pub).
  2. 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 RevokedKeys si 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.

Besoin d'aide sur ce sujet ?

Notre équipe d'experts est là pour vous accompagner dans vos projets.

Contactez-nous

Articles similaires qui pourraient vous intéresser