Les paires de clés SSH, un problème d'expansion. Les certificats sont la solution.

Les paires de clés SSH fonctionnent bien pour trois serveurs. À trente, elles deviennent un passif de sécurité. À trois cents, un cauchemar de conformité. Les clés obsolètes s'accumulent, sans enforcement d'expiration, sans mécanisme de révocation centralisé, ni piste d'audit reliant une clé à un événement de connexion spécifique. Les certificats SSH résolvent ces trois problèmes sans rien changer à la manière dont les ingénieurs se connectent aux serveurs.

Le problème de l'expansion des clés SSH

Selon l'enquête 2024 de Venafi sur la gestion des identités machines, la durée de vie moyenne d'une clé SSH dans une organisation de plus de 100 ingénieurs est de 4,3 ans. Les ingénieurs arrivent, génèrent une paire de clés, collent leur clé publique dans authorized_keys sur chaque serveur dont ils ont besoin, et puis — rien ne change lorsqu'ils partent. Les checklists de départ oublient des serveurs. Les clés persistent.

Les problèmes structurels des paires de clés SSH à l'échelle :

Pas d'expiration. Une clé créée en 2019 est toujours valide en 2026 à moins que quelqu'un ne la supprime manuellement de chaque fichier authorized_keys sur chaque serveur où elle a été ajoutée.
Pas de révocation centralisée. Si une clé privée est volée ou un ordinateur portable perdu, révoquer l'accès signifie se connecter en SSH à chaque serveur affecté et éditer authorized_keys. Dans un environnement de 200 serveurs, cela prend des heures — si vous savez même quels serveurs ont la clé.
Pas de piste d'audit. sshd enregistre l'empreinte de la clé qui a authentifié une session, mais il n'existe aucun enregistrement faisant autorité reliant cette empreinte à l'identité d'un ingénieur spécifique au moment de l'émission. Les empreintes de clés ne sont pas des identités.
Risque de mouvement latéral. Une clé volée donne accès à tous les serveurs où elle a été ajoutée. Il n'y a pas de restriction de portée, pas de limite de temps, ni de moyen de limiter une clé à une adresse IP source spécifique après l'émission.

Aucun de ces problèmes n'est hypothétique. La fuite de Twitter en 2020 impliquait un initié utilisant un accès SSH obtenu par ingénierie sociale. L'expansion des clés a considérablement compliqué le périmètre de l'incident.

Comment fonctionnent les certificats SSH

Une autorité de certification SSH (CA) n'est elle-même qu'une paire de clés SSH — généralement ed25519. Au lieu de distribuer les clés publiques des utilisateurs aux serveurs, vous configurez les serveurs pour qu'ils fassent confiance à la clé publique de la CA. La CA signe ensuite les clés publiques individuelles des utilisateurs pour produire des certificats.

Un certificat SSH signé comprend les champs suivants :

Principals : la liste des noms d'utilisateur ou des groupes pour lesquels ce certificat est valide (par ex., alice, eng-team)
Valide après / Valide avant : des timestamps stricts — le certificat est cryptographiquement invalide en dehors de cette fenêtre
Restriction d'adresse source : plage IP optionnelle depuis laquelle ce certificat peut être utilisé
Extensions : capacités comme permit-pty, permit-port-forwarding, permit-agent-forwarding — chacune peut être accordée ou refusée par certificat
Numéro de série du certificat : un identifiant unique qui apparaît dans les logs d'auth de sshd

Le fichier sshd_config du serveur contient une seule ligne : TrustedUserCAKeys /etc/ssh/ca_user_key.pub. C'est la seule modification de configuration nécessaire. Fini la gestion des fichiers authorized_keys.

Configurer votre propre CA en 15 minutes

Vous n'avez pas besoin de Teleport ni de HashiCorp Vault pour commencer. OpenSSH embarque tout le nécessaire.

Étape 1 — Générer la clé de la CA sur un hôte sécurisé :

ssh-keygen -t ed25519 -f /etc/ssh/ca_user_key -C "CA utilisateur SSH"

Gardez ca_user_key (privée) hors ligne ou dans un gestionnaire de secrets. Distribuez ca_user_key.pub sur chaque serveur.

Étape 2 — Configurer sshd sur chaque serveur :

TrustedUserCAKeys /etc/ssh/ca_user_key.pub

Rechargez sshd. Le serveur acceptera désormais tout certificat signé par cette CA, sous réserve des contraintes de principal et de validité.

Étape 3 — Délivrer un certificat à un utilisateur :

ssh-keygen -s ca_user_key -I "[email protected]" -n alice -V +8h alice.pub

Cela produit alice-cert.pub. Le flag -I définit l'ID de la clé (enregistré lors de l'auth), -n alice définit le principal, -V +8h le rend valide pour 8 heures à partir de maintenant.

Étape 4 — L'utilisateur se connecte normalement :

ssh alice@prod-server-01

OpenSSH présente automatiquement le certificat avec la clé privée. Pas de changement dans le workflow de l'utilisateur.

Certificats à courte durée de vie + plateformes d'identité

L'émission manuelle de certificats fonctionne pour les petites équipes. Pour la production à grande échelle, vous voulez une émission automatisée liée à votre fournisseur d'identité.

Teleport agit à la fois comme CA SSH et comme couche proxy. Les ingénieurs s'authentifient via Okta ou Azure AD SSO, Teleport émet un certificat de courte durée (12 heures par défaut) et toute l'activité de session est enregistrée. Révoquer l'accès signifie retirer l'utilisateur du groupe IdP — aucune modification de serveur nécessaire.

Le SSH Secrets Engine de HashiCorp Vault offre la fonctionnalité de CA sans la couche proxy. Configurez un rôle Vault :

vault write ssh/roles/eng-ssh \
  key_type=ca \
  allowed_users="*" \
  default_user=ubuntu \
  ttl=8h \
  max_ttl=24h \
  allowed_extensions="permit-pty,permit-port-forwarding"

Les ingénieurs s'authentifient auprès de Vault (via OIDC/Okta/Azure AD + MFA), demandent un certificat avec vault ssh -role eng-ssh -mode ca -mount-point ssh user@host, et reçoivent un certificat limité dans le temps. Vault enregistre chaque émission avec l'identité du demandeur.

AWS EC2 Instance Connect utilise le même modèle nativement pour les instances EC2 — poussez une clé publique temporaire (valide 60 secondes), connectez-vous, terminé. Plus du tout de authorized_keys persistent.

La révocation de clé dans l'un de ces systèmes est instantanée. Arrêter la CA de délivrer de nouveaux certificats à un utilisateur signifie que tous ses certificats existants expirent au maximum en quelques heures. Comparez cela à la chasse manuelle aux entrées de clés sur des centaines de serveurs.

Certificats d'hôte : l'autre moitié

Les certificats SSH fonctionnent dans les deux sens. Les certificats utilisateur authentifient les utilisateurs auprès des serveurs ; les certificats d'hôte authentifient les serveurs auprès des utilisateurs.

Sans certificats d'hôte, SSH utilise le TOFU (Trust On First Use) — la première fois que vous vous connectez à un hôte, il vous est demandé d'accepter son empreinte. Cela est vulnérable aux attaques MITM via de fausses clés d'hôte, et l'invite habitue les ingénieurs à cliquer sur les avertissements de sécurité.

Avec une CA d'hôte, vous signez la clé d'hôte de chaque serveur :

ssh-keygen -s ca_host_key -I "prod-server-01" -h -n prod-server-01,10.0.1.5 -V +52w /etc/ssh/ssh_host_ed25519_key.pub

Ajoutez la CA au fichier known_hosts du client :

@cert-authority *.internal.example.com ssh-ed25519 AAAA... CA Hôte SSH

Désormais, chaque serveur de votre flotte est automatiquement approuvé par chaque client. Plus d'invites d'empreinte. Pas de TOFU. Si un serveur est compromis et que sa clé d'hôte change, les clients rejettent immédiatement la connexion.

La piste d'audit que vous obtenez réellement

Avec l'authentification par certificat, chaque événement de connexion porte un numéro de série de certificat. Activez la journalisation verbose dans sshd_config :

LogLevel VERBOSE

Les entrées de logs d'auth ressemblent désormais à :

Accepted publickey for alice from 10.0.1.22 port 52341 ssh2: ED25519-CERT SHA256:... ID [email protected] (serial 42) CA ED25519 SHA256:...

Le numéro de série 42 correspond à une entrée spécifique du journal d'émission Vault ou à un événement d'audit Teleport avec le contexte d'identité complet : qui a demandé le certificat, quand, depuis quelle IP, après authentification via quelle méthode MFA. C'est la piste d'audit dont les outils SIEM et les auditeurs de conformité ont réellement besoin — pas une empreinte de clé séparée de toute identité.

Chemin de migration

Migrer une flotte existante est simple si fait dans l'ordre :

Auditez d'abord. Exécutez find / -name authorized_keys 2>/dev/null sur votre flotte (ou utilisez un outil de gestion de configuration). Documentez chaque clé, quand elle a été ajoutée et à qui elle appartient.
Ajoutez la confiance CA sans supprimer les clés existantes. Ajoutez TrustedUserCAKeys dans sshd_config sur tous les serveurs. L'authentification par clé existante continue de fonctionner.
Délivrez des certificats à tous les ingénieurs. Faites générer une nouvelle paire de clés à chaque ingénieur et faites-la signer, ou inscrivez-les dans Teleport/Vault pour une émission automatisée de certificats.
Fonctionnez en parallèle pendant 30 jours. Les deux méthodes fonctionnent pendant cette fenêtre. Surveillez les logs d'auth pour confirmer que toutes les connexions de production passent par les certificats.
Supprimez les clés brutes. Après 30 jours de connexions propres uniquement par certificat, retirez les anciennes entrées authorized_keys.
Clé de secours. Gardez une paire de clés à longue durée de vie dans un coffre de secrets scellé (par ex., HashiCorp Vault avec politique de rupture de glace) pour un accès d'urgence si la CA devient indisponible. Auditez l'accès trimestriellement.

La migration ne nécessite aucun temps d'arrêt et les ingénieurs ne remarquent quasiment aucun changement dans leur workflow quotidien — sauf qu'ils n'ont plus d'invites d'empreinte pour les nouveaux serveurs.

Conclusion

Le SSH basé sur les certificats n'est pas plus complexe à utiliser que l'authentification par clé. Pour les ingénieurs, l'expérience est identique ou plus simple — pas de distribution manuelle de clés, pas d'invites d'empreinte, pas de "colle ta clé publique dans ce fil Slack". Pour les équipes de sécurité, cela offre un contrôle centralisé, une révocation instantanée, une expiration forcée et une piste d'audit par session liée à des identités réelles. Les outils — OpenSSH, Teleport, HashiCorp Vault, AWS EC2 Instance Connect — sont matures et bien documentés. La seule chose qui empêche la plupart des équipes de migrer est l'inertie.