Certificats SSH pour agents IA et conservation locale des identifiants

Les certificats SSH et la conservation locale des identifiants fonctionnent ensemble. Un certificat fournit à un serveur SSH une déclaration limitée dans le temps concernant une clé publique. La conservation locale empêche l’identifiant privé correspondant d’entrer dans le contexte, les fichiers, les sous-processus et les journaux d’un agent IA. Considérer l’un comme un substitut à l’autre laisse une faille qui se manifestera au pire moment.

La version populaire de cette architecture affirme qu’un certificat de 15 minutes rend tout sûr. Ce n’est pas le cas. Si l’agent peut lire la clé privée, il peut continuer à l’utiliser jusqu’à l’expiration du certificat, demander un autre certificat s’il peut atteindre le service d’émission ou laisser une copie dans un espace de travail qui survivra à l’exécution. Une courte durée de validité réduit la période pendant laquelle le serveur accepte le certificat. Elle ne retire pas la capacité au processus qui détient le secret.

Pour les agents capables de modifier l’infrastructure, utilisez les certificats pour réduire la durée d’acceptation et la conservation locale pour empêcher la divulgation de l’identifiant privé. Concevez ensuite le renouvellement, l’interruption et la révocation comme un seul système opérationnel. Les détails comptent davantage que la durée du certificat indiquée sur un schéma.

Un certificat limite l’acceptation, pas la possession

Un certificat utilisateur OpenSSH est une clé publique signée, accompagnée de contraintes. Le serveur SSH vérifie la signature de l’autorité de certification et contrôle des champs comme le type de certificat, l’intervalle de validité, la liste des principaux, les options critiques et les extensions. Le client doit toujours prouver qu’il contrôle la clé privée correspondant à la clé publique certifiée.

Cette distinction est constamment brouillée. Un certificat est une donnée publique. Vous pouvez placer id_ed25519-cert.pub à côté d’une clé privée, le copier sur un client et l’inspecter librement. Le secret reste id_ed25519. Si un agent reçoit ce fichier privé, la courte durée de validité limite seulement la période pendant laquelle un certificat émis fonctionne. L’agent détient toujours un identifiant de signature réutilisable.

OpenSSH documente le format des certificats dans PROTOCOL.certkeys et présente les contrôles habituels de création dans le manuel de ssh-keygen. La commande de signature utilise une clé privée d’autorité avec -s, une chaîne d’identité avec -I, les principaux autorisés avec -n et une spécification de validité avec -V. Ce sont des paramètres d’autorisation, pas des métadonnées décoratives. Un serveur doit être configuré pour faire confiance à l’autorité et interpréter les principaux avant qu’ils puissent influer sur l’accès.

Considérez deux architectures :

• Dans la première, un agent reçoit id_ed25519, un certificat et le point d’accès de l’autorité. Il peut signer lui-même les défis SSH et peut être capable d’effectuer de futures demandes de certificats.
• Dans la seconde, un exécuteur local conserve id_ed25519 dans un espace protégé. L’agent demande une action SSH nommée, et l’exécuteur gère l’authentification SSH sans renvoyer de données privées.

Les deux architectures peuvent utiliser le même certificat. Seule la seconde empêche une injection dans les instructions de l’agent, un module compromis ou un sous-processus trop curieux de copier l’identifiant privé.

N’utilisez pas non plus le champ d’identité d’un certificat comme preuve de conservation. La valeur de -I aide les humains à relier les registres d’émission et d’accès, mais tout appelant capable de demander des certificats peut choisir une identité impressionnante. Associez l’émission à une clé publique connue et à une session d’agent connue. Si votre émetteur accepte des clés publiques et des chaînes d’identité arbitraires, votre piste d’audit deviendra fictive sous pression.

La conservation locale change le type d’échec à prévoir

Conserver un identifiant localement transforme un incident d’exfiltration de secret en incident d’autorisation d’action. C’est un meilleur problème, mais il faut tout de même le traiter. L’agent peut demander une commande destructive, viser le mauvais hôte ou utiliser une session approuvée plus longtemps que prévu par l’opérateur.

Le composant local doit conserver l’identifiant SSH privé et effectuer lui-même l’opération de protocole. L’agent doit recevoir la sortie de la commande, son code de retour et des informations de diagnostic limitées. Il ne doit recevoir ni la clé privée sous forme de texte, ni le chemin d’un fichier temporaire, ni une variable d’environnement, ni un socket d’agent SSH qu’il pourrait transférer, ni une fausse valeur masquée qu’un autre outil pourrait résoudre.

Un mauvais compromis courant consiste à monter un répertoire de secrets en lecture seule dans l’environnement de l’agent. La lecture seule protège contre les modifications, pas contre la lecture. Un autre mauvais compromis consiste à placer la clé privée dans un agent SSH et à donner à chaque processus enfant accès à SSH_AUTH_SOCK. Cela peut convenir à un shell interactif très contrôlé, mais un agent de programmation autonome lance des outils, des exécuteurs de tests, des hooks de paquets et des processus auxiliaires. Chacun élargit le nombre de processus capables de demander une signature à l’agent.

La conservation locale vous donne aussi un point utile pour le contrôle humain. Une personne peut approuver la première action d’un nouveau processus, exiger une approbation à chaque utilisation d’identifiants sensibles ou verrouiller complètement le coffre. Ces contrôles ne remplacent pas l’autorisation du serveur. Ils décident simplement si un processus peut tenter une action.

Gardez cette limite étroite. Le composant qui détient la clé privée ne doit pas accepter du texte shell arbitraire et l’exécuter aveuglément parce que l’agent l’a fourni. Il doit connaître l’hôte, le compte cible et la demande d’action qu’il va exécuter, puis enregistrer ces éléments avant ou pendant l’exécution. Si vous ne pouvez pas reconstituer quel processus a demandé ssh deploy@host, la conservation locale n’est plus qu’un emballage de secret peu responsable.

La conséquence pratique est simple : le renouvellement du certificat doit actualiser l’autorisation publique, tandis que la conservation locale continue de contrôler la signature privée. Ne recréez pas l’identifiant privé chaque fois qu’un certificat expire, sauf si vous avez une raison distincte de le faire tourner.

La durée du certificat doit suivre la tolérance aux interruptions

Choisissez la validité selon la durée pendant laquelle vous pouvez tolérer un identifiant déjà émis après l’arrêt des nouveaux travaux. La réponse varie pour une analyse en lecture seule, un processus de déploiement et un agent capable de modifier les contrôles d’accès.

Commencez par une durée qui laisse de la place au travail réel. Le renouvellement des certificats échoue plus souvent que prévu : les ordinateurs portables se mettent en veille, les routes VPN changent, l’autorité est brièvement indisponible, une commande longue maintient une connexion ouverte ou l’horloge de la machine dérive. Une durée très courte transforme les interruptions ordinaires en source constante de logique de nouvelle tentative et de contournements tentants.

Pour de nombreuses tâches autonomes, un certificat valide de 15 à 60 minutes constitue un premier réglage raisonnable. Utilisez la limite basse lorsque le compte peut agir sur des systèmes de production. N’utilisez une fenêtre plus longue que si la tâche en a réellement besoin et si vous pouvez l’expliquer. Un certificat de plusieurs heures pour une tâche de dix minutes est généralement une commodité déguisée en nécessité opérationnelle.

Ne confondez pas la validité du certificat avec la durée de la connexion SSH. SSH s’authentifie lors de l’établissement de la connexion. Normalement, un serveur n’expulse pas une session déjà authentifiée lorsque le certificat arrive à expiration. Le multiplexage des connexions peut rendre cela encore moins intuitif : une commande ultérieure peut réutiliser une connexion maître déjà authentifiée au lieu d’effectuer une nouvelle vérification du certificat.

Ce comportement change la conception :

1. Définissez la validité du certificat pour limiter les nouvelles authentifications.
2. Limitez séparément la durée des commandes ou des sessions dans l’exécuteur local.
3. Évitez de remettre à un agent un socket de contrôle multiplexé réutilisable.
4. Interrompez les sessions actives en cas d’urgence lorsque l’action elle-même doit s’arrêter.

L’option ControlMaster de ssh_config est utile pour accélérer les sessions interactives, mais elle remet en cause les hypothèses simples concernant l’authentification de chaque commande. Pour les tâches autonomes, désactivez le multiplexage sur les cibles sensibles ou laissez l’exécuteur posséder la connexion et la fermer. Ne laissez pas un agent hériter d’un chemin de contrôle qui reste authentifié alors que son approbation ou la fenêtre de validité du certificat aurait dû prendre fin.

La synchronisation des horloges fait aussi partie de cette question. Un certificat possède un intervalle de validité absolu. Si l’hôte émetteur et le serveur cible présentent un écart important, un certificat fraîchement créé peut sembler expiré ou pas encore valide. Surveillez la synchronisation de l’heure des deux côtés et refusez par défaut lorsque le serveur rejette la fenêtre de validité. Ne contournez pas un problème d’horloge en émettant un certificat beaucoup plus long.

Le renouvellement doit prouver que la même limite de conservation existe toujours

Un service de renouvellement ne doit émettre un nouveau certificat qu’après avoir relié la demande à l’identifiant conservé localement, à la session actuelle de l’agent et à la portée d’autorisation demandée. Accepter simplement une clé publique dans une requête HTTP ne prouve rien sur le contrôle de la clé privée correspondante.

Le flux le plus propre demande à l’exécuteur local de prouver, lors du renouvellement, qu’il possède sa clé publique enregistrée. L’émetteur vérifie cette preuve, contrôle la session active et le principal demandé, signe la clé publique et ne renvoie que le certificat public. L’exécuteur associe ce certificat à l’identifiant privé qu’il conserve en interne pour la prochaine connexion SSH.

Une commande de création de certificat peut ressembler à ceci sur l’émetteur :

ssh-keygen -s agent_user_ca -I run-4821 -n deploy-prod -V +30m agent-run-4821.pub

Cette commande signe agent-run-4821.pub avec la clé privée de l’autorité. Elle crée un certificat public associé, généralement nommé agent-run-4821-cert.pub. La chaîne run-4821 aide à relier les registres, deploy-prod est le principal autorisé et +30m demande un intervalle de trente minutes. L’émetteur doit générer lui-même cette chaîne d’identité au lieu de faire confiance à une étiquette fournie par l’agent.

Inspectez chaque nouveau certificat avant de laisser l’automatisation en dépendre :

ssh-keygen -L -f agent-run-4821-cert.pub

La sortie indique le type de certificat, l’empreinte de l’autorité signataire, l’identité, le numéro de série, la période de validité, les principaux, les options critiques et les extensions. Intégrez cette inspection aux tests de votre émetteur. Un principal manquant, une période qui commence dans le futur ou une extension inattendue apparaîtraient sinon comme un déploiement échoué, avec quelqu’un qui chercherait une clé de secours à longue durée de vie.

Renouvelez le certificat avant que le travail n’ait besoin d’une nouvelle connexion SSH, et non à la seconde exacte de l’expiration. L’exécuteur peut demander un remplacement vers la fin de l’intervalle, tant que le certificat actuel fonctionne encore. Il doit aussi refuser de commencer une commande s’il ne reste pas assez de temps de validité pour sa durée autorisée. Ce contrôle évite qu’une tâche commence une écriture importante juste avant l’échec de la prochaine authentification.

Rendez le renouvellement idempotent au niveau de la demande. Une réponse perdue peut amener un client à réessayer alors que l’émetteur a déjà créé un certificat valide. Enregistrez un identifiant de demande, un identifiant de session, l’empreinte de la clé publique, le principal et l’expiration. En cas de nouvelle tentative, renvoyez le certificat déjà émis lorsque les paramètres correspondent. S’ils diffèrent, refusez la demande au lieu de deviner laquelle l’agent voulait effectuer.

Les principaux et la politique du serveur déterminent ce que le certificat peut faire

Un certificat indique qui peut s’authentifier. Le serveur décide toujours quel compte local accepte cette identité et ce que ce compte peut faire. Si vous autorisez un certificat d’agent à s’authentifier comme un compte administrateur partagé et très étendu, une courte durée de validité ne rattrapera pas une autorisation laxiste.

OpenSSH peut faire confiance à une autorité de certification utilisateur via TrustedUserCAKeys. Vous pouvez ensuite associer les principaux acceptés avec AuthorizedPrincipalsFile ou AuthorizedPrincipalsCommand. Cette dernière option est utile lorsqu’un serveur a besoin d’une association de comptes gérée de manière centralisée, mais elle ajoute une dépendance de disponibilité à la connexion. Un fichier statique de principaux est moins flexible et souvent plus facile à comprendre pour un parc restreint.

Une configuration serveur restrictive peut ressembler à ceci :

TrustedUserCAKeys /etc/ssh/agent_user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
RevokedHostKeys /etc/ssh/revoked_agent_credentials.krl

Pour un compte local nommé deploy, /etc/ssh/auth_principals/deploy pourrait contenir uniquement :

deploy-prod

Cette organisation signifie que le serveur accepte un certificat de l’autorité désignée uniquement lorsqu’il contient deploy-prod comme principal et n’a pas été révoqué par la KRL configurée. Testez la version exacte d’OpenSSH installée sur vos serveurs. Les directives de configuration et le comportement des certificats sont stables dans leur principe, mais le conditionnement des distributions et les anciennes versions peuvent modifier ce sur quoi vous pouvez compter.

Les options critiques et les extensions des certificats peuvent encore restreindre leur usage. OpenSSH prend en charge des options critiques telles que force-command et source-address, ainsi que des extensions comme permit-pty, permit-port-forwarding et permit-agent-forwarding. Utilisez-les lorsque le flux cible a une forme étroite. Un agent qui ne lance qu’un outil de déploiement ne doit pas recevoir par accident un shell interactif général.

N’ajoutez pas une capacité générique permit-pty à un certificat d’agent simplement parce que quelqu’un pourrait avoir besoin de déboguer plus tard. Émettez plutôt un identifiant de diagnostic séparé et explicitement approuvé. Les extensions ajoutées par commodité restent souvent bien après la tâche exceptionnelle qui les justifiait.

La révocation d’urgence exige davantage que l’attente de l’expiration

Une courte durée de validité suffit pour le confinement ordinaire. Si vous arrêtez l’émission et que le certificat expire dans trente minutes, les nouvelles authentifications SSH s’arrêteront à la fin de cette fenêtre. Cela peut suffire si vous avez intercepté une tâche erronée avant qu’elle n’atteigne une cible sensible. C’est insuffisant lorsqu’un identifiant privé a peut-être été divulgué ou qu’un agent a commencé une activité nuisible.

Votre première mesure de confinement consiste à arrêter les nouvelles émissions pour la session, l’identifiant ou l’autorité concernés. Empêchez ensuite les identifiants déjà émis de s’authentifier là où l’urgence l’exige. Dans OpenSSH, une liste de révocation de clés, ou KRL, permet aux serveurs de rejeter des certificats, des clés publiques ou une autorité signataire donnée.

Pour ajouter un certificat émis à une KRL, un opérateur peut utiliser une commande de cette forme :

ssh-keygen -k -f revoked_agent_credentials.krl -s agent_user_ca.pub agent-run-4821-cert.pub

L’argument -s identifie l’autorité qui a signé le certificat. Distribuez la KRL obtenue aux serveurs cibles, conservez le chemin associé à RevokedHostKeys et rechargez sshd selon votre procédure. Testez tout le parcours à l’avance : créez un certificat, authentifiez-vous avec succès, ajoutez-le à la KRL, distribuez le fichier, rechargez sshd et vérifiez qu’une nouvelle authentification échoue.

Une KRL n’est pas un bouton d’arrêt centralisé. Chaque serveur SSH doit recevoir le fichier et le lire. Si un hôte est inaccessible, hors ligne ou géré par une configuration distincte, il peut continuer à accepter le certificat jusqu’à son expiration. C’est pourquoi un intervalle de validité court reste utile même lorsque vous utilisez des listes de révocation.

Si vous soupçonnez la clé privée de l’autorité elle-même, révoquer des certificats individuels n’est pas une réponse adaptée à l’échelle du problème. Retirez ou remplacez la confiance accordée à cette autorité sur les serveurs concernés, créez une nouvelle autorité et recertifiez uniquement les identifiants auxquels vous faites encore confiance. Utilisez une autorité distincte pour les accès des agents afin que cette opération ne bloque pas les accès humains d’urgence. Conservez un accès de secours testé, mais hors de portée de l’agent, et consignez chaque utilisation.

Enfin, arrêtez les sessions actives. La distribution d’une KRL bloque les authentifications futures, mais ne ferme pas nécessairement une connexion SSH déjà acceptée par le serveur. Utilisez les contrôles de session de l’hôte, le superviseur de tâches ou les contrôles réseau pour arrêter le travail en cours. Examinez ensuite les commandes déjà exécutées, car la révocation d’un identifiant ne peut pas annuler un déploiement ni restaurer un fichier supprimé.

Un émetteur de certificats doit refuser par défaut en cas d’incertitude

L’émetteur doit refuser le renouvellement lorsqu’il ne peut pas vérifier l’identité de l’exécuteur local, l’état de la session, le principal demandé ou l’autorisation requise pour cette portée. La pression exercée par les exigences de disponibilité pousse les équipes à transformer ces contrôles en avertissements. Cette décision transforme une panne temporaire en émission illimitée d’identifiants.

Prévoyez les défaillances courantes avant le déploiement. Si l’émetteur est inaccessible, laissez un certificat existant fonctionner jusqu’à son expiration normale, mais ne le remplacez pas silencieusement par une clé privée statique. Si le coffre local est verrouillé, refusez l’action. Si une approbation humaine est requise et que personne ne répond, faites expirer le travail au lieu de laisser l’agent conserver indéfiniment cette approbation.

Un registre de renouvellement utile contient l’empreinte de l’autorité, le numéro de série du certificat, l’heure d’émission, l’heure d’expiration, l’empreinte de la clé publique, le principal demandé, l’identité du processus agent, l’identifiant de session, la catégorie de cible et le résultat de l’approbation. Le certificat contient une partie de ces informations, mais il ne vous indique pas si la demande a suivi le chemin de contrôle local prévu.

L’émetteur doit aussi empêcher toute dérive de portée lors du renouvellement. Une session approuvée pour deploy-prod ne doit pas être renouvelée vers root-prod, un principal plus large, simplement parce que l’agent a modifié son plan. Exigez une nouvelle limite d’autorisation pour un autre compte, groupe de cibles ou type de commande. C’est souvent ainsi que les tâches autonomes longues deviennent dangereuses : la session commence avec une portée étroite, puis accumule des exceptions dans une logique de renouvellement que personne ne réexamine.

Utilisez des registres distincts pour l’émission et l’exécution. L’émission prouve que l’autorité a autorisé un certificat. Les journaux du serveur SSH et les registres d’activité de l’exécuteur prouvent où un identifiant a été utilisé et quelle commande a été exécutée. Il vous faut les deux lorsqu’un opérateur cherche à savoir si un certificat a été émis à tort ou correctement émis mais mal utilisé.

Testez la révocation comme un exercice opérationnel chronométré

Un runbook qui dit de révoquer le certificat est incomplet tant qu’il ne nomme pas les systèmes, les fichiers, les droits d’accès, l’échec attendu et la personne qui peut agir lorsque l’émetteur est indisponible. Effectuez l’exercice sur une cible hors production, avec de vrais certificats et le même mécanisme de distribution que celui utilisé en production.

Suivez cette séquence :

1. Émettez un certificat avec un numéro de série connu et un intervalle court documenté.
2. Authentifiez-vous une fois et enregistrez l’événement d’acceptation côté serveur.
3. Désactivez le renouvellement pour la session de l’agent concernée.
4. Ajoutez le certificat à la KRL, distribuez-la, puis rechargez les instances sshd cibles.
5. Tentez une nouvelle connexion SSH et confirmez que le serveur la rejette, puis terminez la session active d’origine si elle existe.

Mesurez le temps réel entre la demande de confinement et le rejet sur chaque groupe de serveurs. Ne publiez pas un objectif que vous n’avez jamais observé. Le résultat dépend de la rapidité avec laquelle votre système de configuration distribue la KRL et de la fiabilité avec laquelle il recharge sshd.

Testez aussi les cas inconfortables. Révoquez un certificat lorsqu’un hôte cible est inaccessible. Révoquez-le pendant une connexion multiplexée existante. Révoquez-le alors que la machine locale est en veille et que le renouvellement ne peut pas aboutir. Révoquez-le après l’approbation d’une session par un opérateur, mais avant la première commande. Chaque résultat vous indique si vos contrôles bloquent l’émission, une nouvelle authentification ou l’exécution active. Ce sont des contrôles différents, et les appeler tous « révocation » crée des hypothèses dangereuses.

Conservez les preuves de l’exercice. Gardez le certificat émis, la mise à jour de la KRL, le registre de l’exécuteur et le journal de rejet du serveur cible. Lorsqu’un incident réel survient, cet ensemble fournit aux intervenants un parcours de commande vérifié, plutôt qu’un document devenu une simple espérance avec le temps.

Reliez approbation, audit et accès SSH

L’approbation humaine n’est utile que si elle correspond au processus qui l’utilisera. Approuver un processus d’arrière-plan non identifié, c’est prendre le risque d’approuver la mauvaise action. Le réviseur doit voir qui a signé le processus, quelle session il démarre et si l’identifiant SSH demandé possède une portée ordinaire ou sensible.

Sallyport conserve les identifiants SSH dans son coffre local chiffré et exécute SSH via son utilitaire intégré. Un agent compatible avec MCP n’a donc pas besoin de la clé SSH privée dans son propre environnement. Ses journaux de session et d’activité peuvent relier une approbation humaine au processus agent et aux enregistrements d’action qui suivent.

La piste d’audit doit fournir des preuves d’intégrité, en plus d’une consultation pratique. Sallyport projette ses journaux depuis un journal d’audit chiffré et chaîné par hachage, et sp audit verify permet à un opérateur de vérifier cette chaîne hors ligne sans accès au coffre. Effectuez cette vérification pendant l’analyse d’un incident et lors de l’export des preuves ; une simple liste d’activités lisible ne prouve pas que personne n’a supprimé un événement gênant.

Ne rendez pas le système d’audit responsable d’une politique d’accès qu’il n’applique pas. Le serveur SSH doit toujours faire confiance à la bonne autorité, accepter uniquement les principaux prévus, lire la KRL actuelle et restreindre le compte cible. L’exécuteur local doit toujours protéger les identifiants privés et demander les approbations que vous avez choisies. Les journaux fournissent des preuves et des retours opérationnels. Ils ne corrigent pas un compte doté de permissions excessives.

La meilleure première mesure n’est pas de réduire davantage la durée du certificat. Inventoriez les actions des agents qui nécessitent SSH, attribuez à chacune un principal et un compte restreints, placez l’identifiant privé sous contrôle local, puis répétez le parcours qui arrête l’émission, distribue la révocation et termine les sessions actives. Une fois ce processus fiable, choisissez la durée de certificat la plus courte que votre système de renouvellement réel peut maintenir.