Certificats SSH et risques de l’agent forwarding

Secure Shell (SSH) reste le canal d’administration privilégié des infrastructures, donc une cible de choix pour le vol d’identités techniques. La clé statique réduit les mots de passe exposés, mais ne résout ni la durée de vie excessive des accès ni la délégation imprudente de l’agent. Les certificats SSH sont la réponse à privilégier pour les accès humains et automatisés à durée contrôlée.

→ Lire l’explication complète de la marmotte

Authentification SSH par clé : le minimum, pas le sommet

Une paire de clés SSH associe une clé privée, conservée par le client, et une clé publique, déclarée sur le serveur. Lors de l’authentification, le client prouve la possession de la clé privée en signant des éléments de la session. La clé privée ne traverse pas le réseau. C’est la garantie centrale, et elle est nettement préférable à un mot de passe réutilisable.

Choisir Ed25519 pour les nouvelles clés. L’algorithme fournit des clés courtes, des signatures rapides et une implémentation largement disponible dans OpenSSH. RSA reste nécessaire pour certains équipements anciens, mais imposer au minimum 3072 bits et refuser ssh-rsa, qui désigne la signature SHA-1 dans OpenSSH. Ne pas confondre une clé RSA avec le nom d’algorithme de signature historique : cette confusion a produit assez de configurations bancales pour meubler un cimetière de fichiers sshd_config.

La clé privée doit être chiffrée au repos par une phrase de passe robuste. Ce chiffrement protège contre le vol du fichier, pas contre un poste déjà compromis ni contre un agent déverrouillé. Une clé déposée sans phrase de passe dans une image de conteneur, un dépôt Git ou un répertoire de déploiement est déjà perdue, même si personne n’a encore pris le temps de l’exploiter.

Côté serveur, désactiver l’authentification par mot de passe pour les comptes administratifs :

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

# Refuser l'ancien nom d'algorithme RSA utilisant SHA-1.
PubkeyAcceptedAlgorithms -ssh-rsa

Cette configuration suppose qu’un accès de secours testé existe avant rechargement du démon. Une console hors bande, une session existante conservée ou un compte de récupération sous contrôle sont nécessaires. Se verrouiller dehors en durcissant SSH n’est pas une démonstration de maturité, seulement une façon coûteuse de redécouvrir l’accès physique.

Les clés publiques statiques dans ~/.ssh/authorized_keys posent un problème de cycle de vie. Elles n’embarquent ni identité vérifiée, ni expiration obligatoire, ni inventaire central fiable. Retirer une clé exige de modifier chaque cible, puis de prouver que toutes les copies ont réellement disparu. Cette méthode reste acceptable pour une clé de récupération très rare, stockée et contrôlée séparément. Elle ne l’est pas pour une population d’administrateurs, de robots CI/CD (Continuous Integration and Continuous Delivery) ou de fournisseurs externes.

La gestion des secrets applicatifs relève d’une discipline complémentaire : une clé de connexion ne doit pas devenir un secret distribué sans traçabilité. Les principes de coffre, de rotation et de séparation des identités sont détaillés dans la page Cryptographie.

Agent SSH et agent forwarding : délégation de signature, pas transport de clé

Un agent SSH conserve des clés privées déverrouillées en mémoire et répond localement aux demandes de signature. ssh-agent évite de ressaisir la phrase de passe à chaque connexion. Cette commodité est légitime sur un poste administré, avec durée de vie limitée des clés chargées et verrouillage de session. Elle ne rend pas le poste de travail digne de confiance par magie. Aucun démon Unix n’a ce pouvoir, malgré les slides qui promettent parfois une transcendance post-humaine.

L’agent forwarding, activé par ForwardAgent yes ou ssh -A, expose un socket de l’agent local à travers la session distante. La clé privée n’est pas copiée sur l’hôte intermédiaire, mais cet hôte peut demander des signatures à l’agent tant que le transfert est actif. Cette nuance est décisive : un serveur de rebond compromis peut utiliser l’identité transférée pour atteindre les cibles autorisées. Il ne vole pas nécessairement la clé, il emprunte son pouvoir. Pour l’incident, la différence philosophique apporte peu de réconfort.

La règle est donc nette : ne jamais activer globalement l’agent forwarding. L’autoriser seulement vers un bastion administré, pour une destination nommée, lorsque l’architecture impose réellement un rebond et qu’aucune alternative ne convient. Préférer ProxyJump, qui établit le chemin réseau via le bastion tout en gardant l’authentification vers la cible sur le poste source. ProxyJump réduit la nécessité de déléguer l’agent, mais ne remplace pas les contrôles réseau ni l’authentification des hôtes.

Pour les clés qui doivent exceptionnellement être transférées, utiliser une clé matérielle FIDO (Fast IDentity Online) lorsque le client et la politique d’accès le permettent. Les clés sk-ssh-ed25519 requièrent une interaction matérielle ou une présence utilisateur selon leur configuration. Elles limitent l’usage silencieux depuis un hôte distant, sans annuler le risque d’une session locale déjà compromise.

Le transfert doit aussi être interdit côté serveur lorsque le compte n’en a pas besoin :

# Dans ~/.ssh/authorized_keys pour une clé d'automatisation.
# Cette clé ne peut pas transférer d'agent, de port ni ouvrir de terminal.
no-agent-forwarding,no-port-forwarding,no-pty,no-X11-forwarding ssh-ed25519 AAAAC3... robot-deploiement

Les restrictions authorized_keys sont attachées à une clé, pas à un utilisateur entier. Elles constituent un contrôle de moindre privilège utile pour les robots. Elles ne remplacent pas les permissions Unix, les contrôles d’accès applicatifs ou le cloisonnement réseau.

Certificats SSH : identité courte durée et autorité de signature

Un certificat SSH est une clé publique signée par une autorité de certification SSH, appelée CA (Certificate Authority). Le certificat contient notamment une identité, des principaux autorisés, une période de validité, un numéro de série et des options critiques. Le serveur fait confiance à la clé publique de la CA, puis vérifie la signature et les contraintes du certificat présenté.

Le compromis central est direct : les certificats SSH remplacent la distribution lente de clés statiques par une infrastructure de signature et de politique. On gagne l’expiration native, l’identité centralisée, l’audit de l’émission et une révocation mieux structurée. On paie une CA disponible, protégée, surveillée, ainsi qu’un processus d’émission qui ne doit pas devenir un distributeur automatique de privilèges. Ce coût est justifié dès que plusieurs systèmes ou plusieurs identités administratives existent. En dessous, une clé statique fortement gouvernée peut suffire, mais elle doit rester l’exception documentée.

Séparer au minimum la CA utilisateur de la CA hôte. La première signe les certificats présentés par les personnes et les automatisations. La seconde signe les clés publiques des serveurs. Mélanger les deux agrandit inutilement le rayon d’explosion d’une clé de signature compromise. La séparation des racines et des usages est également un principe majeur des infrastructures de clés publiques.

Côté serveur SSH, déclarer la CA utilisateur dans TrustedUserCAKeys. Associer ensuite les identités du certificat aux comptes locaux par AuthorizedPrincipalsFile ou AuthorizedPrincipalsCommand. Éviter le mappage permissif où tout principal signé peut ouvrir n’importe quel compte local. Un principal admin-production doit être explicitement autorisé là où ce rôle est légitime, pas converti en passe-partout parce que les fichiers de politique fatiguent quelqu’un.

Les certificats hôte résolvent un autre défaut récurrent : le fichier known_hosts appris à la première connexion. Avec @cert-authority, le client valide l’identité de l’hôte contre une CA connue. On élimine les alertes de changement de clé lors du renouvellement légitime, sans accepter aveuglément une nouvelle empreinte. Cette approche rejoint le problème d’authentification de serveur traité par TLS expliqué, mais SSH utilise ses propres formats et sa propre chaîne de confiance.

La durée de validité doit suivre le risque : quelques heures pour l’administration humaine, quelques minutes à quelques heures pour une tâche automatisée, jamais des mois par défaut. Un certificat court ne révoque pas une session déjà établie. Il interdit seulement les nouvelles authentifications après expiration. La fermeture immédiate d’un accès compromis dépend donc aussi de la coupure de session, du retrait des droits en aval et de la détection.

Émission, révocation et exemple de certificat SSH

La clé privée de CA utilisateur mérite une protection équivalente à celle d’une racine de confiance. La conserver dans un HSM (Hardware Security Module) ou un service de signature isolé lorsqu’il existe une intégration fiable avec les outils d’émission. Le HSM protège l’extraction de la clé, pas la décision de signer. Une API d’émission qui accepte n’importe quelle demande authentifiée transforme un HSM en tampon officiel pour mauvaises idées.

L’émetteur doit vérifier l’identité de l’appelant, les groupes d’autorisation, les principaux demandés, la durée, la cible éventuelle et les contraintes de commande. Journaliser chaque émission avec le numéro de série, l’identité source, le principal, l’empreinte de clé et l’horodatage. Le journal doit être exporté vers une supervision indépendante de l’émetteur. Sinon, l’attaquant qui contrôle le service contrôle aussi le récit. Classique, mais toujours très rentable.

Exemple reproductible pour signer une clé utilisateur avec une CA locale de laboratoire :

# Générer la CA utilisateur, à protéger hors de ce laboratoire.
ssh-keygen -t ed25519 -f user_ca -C "CA utilisateurs SSH"

# Générer la clé d'un administrateur.
ssh-keygen -t ed25519 -f admin -C "admin@example.invalid"

# Signer pour le principal linux-admin, valable huit heures.
ssh-keygen -s user_ca \
  -I "admin-20260923" \
  -n linux-admin \
  -V +8h \
  -z 1042 \
  admin.pub

# Vérifier le contenu avant installation ou usage.
ssh-keygen -L -f admin-cert.pub

La révocation s’appuie sur une KRL (Key Revocation List), liste de révocation OpenSSH. Elle peut viser un certificat précis, une plage de numéros de série, une clé ou une CA. Déclarer RevokedHostKeys et distribuer la liste sur les serveurs concernés. La distribution doit être atomique, vérifiée et supervisée : une liste mal propagée n’est pas une révocation, c’est un souhait avec une extension de fichier.

Planifier également la rotation de la CA. Prépublier la nouvelle clé de confiance sur les serveurs, émettre les nouveaux certificats, puis retirer l’ancienne CA après la fenêtre de transition. Ne jamais remplacer brutalement la clé de CA sans chevauchement, sauf compromission avérée. Dans ce cas, révoquer l’ancienne CA, couper les sessions à risque et réémettre les accès. La reprise dépend de procédures préparées, pas d’un canal de discussion ouvert à deux heures du matin.

🐝 Ce qui arrive si on s’en passe

Sans certificats SSH, chaque serveur doit continuer à lire les fichiers authorized_keys, et tout attaquant ayant obtenu un shell sous un compte peut y ajouter sa propre clé publique : cet accès persiste après la rotation de la clé légitime et après la fermeture de la session initiale, car aucune expiration ni aucune autorité ne le contraint. Avec une CA utilisateur, AuthorizedKeysFile none rend cette persistance inopérante. L’attribution des connexions se dégrade aussi : sshd ne journalise qu’une empreinte de clé, sans l’identifiant ni le numéro de série qu’un certificat inscrit dans le journal d’authentification. Relier une connexion suspecte à une personne dépend alors d’un inventaire manuel des clés, souvent incomplet au moment précis où l’enquête en a besoin.

🦫 Explication de la marmotte 🍫

SSH permet de se connecter à distance à une machine pour l’administrer. Au lieu d’envoyer un mot de passe, la personne utilise une clé privée conservée sur son poste. Le serveur possède la partie publique correspondante et demande une preuve mathématique que la clé privée est bien présente. Si la preuve est correcte, la connexion est autorisée.

Un programme local peut garder la clé privée prête à signer pendant une durée limitée. Cela évite de saisir sa phrase secrète à chaque connexion. Mais si ce programme est rendu accessible à une machine distante, cette machine peut demander des signatures et se connecter à d’autres systèmes avec les droits associés. La clé privée ne quitte pas le poste, mais son autorisation peut être utilisée. Cette fonction doit donc rester exceptionnelle.

Les certificats SSH ajoutent une signature faite par une autorité reconnue. Cette signature indique qui peut utiliser une clé, pour quel rôle et jusqu’à quelle heure. Les serveurs font confiance à l’autorité, pas à chaque clé ajoutée manuellement. Si le certificat expire, une nouvelle connexion échoue. Si une clé ou un certificat doit être interdit avant son expiration, une liste de révocation doit être distribuée aux serveurs. Les connexions déjà ouvertes ne disparaissent pas automatiquement : il faut aussi les fermer et retirer les droits nécessaires.

Pages voisines

La citent

Certificats SSH et risques de l’agent forwarding

Elle cite

: les deux pages se citent l’une l’autre.

Certificats SSH et risques de l’agent forwarding

Certificats SSH et risques de l’agent forwarding

Authentification SSH par clé : le minimum, pas le sommet

Agent SSH et agent forwarding : délégation de signature, pas transport de clé

Certificats SSH : identité courte durée et autorité de signature

Émission, révocation et exemple de certificat SSH

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines