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

Les certificats OpenSSH remplacent 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.

Cette approche complète une sécurisation SSH de base et tient la charge à grande échelle.

• 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

• 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.

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

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.

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...

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

• 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.

• 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.

Combinez avec un bastion SSH multi-facteurs ou des tunnels avancés pour une sécurité renforcée.

Avec une CA OpenSSH, vous simplifiez la gestion des accès : on signe, on révoque, on fait tourner.
Les certificats SSH tiennent l'échelle, tracent chaque accès et resserrent la sécurité des parcs d'administration.