Des helpers SSH stateless pour des workflows d'agents IA plus sûrs

Les agents autonomes de programmation ne devraient pas conserver une session SSH d'une exécution à l'autre. Un nouveau contexte d'exécution local pour chaque action rend plus difficile le fait qu'une exécution précédente transmette son autorité, son identité ou des effets de bord inexpliqués à la suivante. Cela donne aussi aux personnes chargées de la revue une unité de preuve claire : ce processus a demandé cette commande sur cet hôte, et le helper a renvoyé ce résultat.

Cela ne rend pas SSH inoffensif. Une nouvelle connexion n'annule pas un déploiement, n'arrête pas un processus en arrière-plan et ne protège pas un compte serveur qui dispose de beaucoup trop d'accès. L'exécution stateless règle un problème plus limité, mais très concret : elle supprime les éléments locaux hérités que les agents sont particulièrement susceptibles d'exploiter par accident.

Les helpers SSH stateless suppriment l'héritage local, pas l'état distant

Un helper SSH stateless crée la connexion nécessaire à une action, exécute cette action, renvoie son résultat, puis se termine sans conserver de transport authentifié pour les appels suivants. L'action suivante recommence avec un nouveau processus helper et une nouvelle tentative de connexion.

La distinction compte, car on parle souvent de « SSH stateless » pour dire que « rien ne persiste nulle part ». C'est faux. SSH offre plusieurs endroits où l'état peut être conservé :

• Le client peut garder une connexion maître, une socket de multiplexage, une entrée known-hosts, une socket d'agent, une configuration ou des fichiers temporaires.
• L'hôte distant peut garder un répertoire de travail, l'historique du shell, un artefact envoyé, un fichier de verrouillage, un processus de service, un cache de paquets et une base de données modifiée.
• Le système d'autorisation peut conserver un compte, un certificat SSH, une clé publique et des permissions.

Un helper stateless concerne la première catégorie. Il refuse qu'un appel ultérieur de l'agent hérite discrètement de la connexion active ou du contexte d'identifiants local du précédent appel. Le côté distant reste un véritable ordinateur, avec de véritables conséquences.

C'est pourquoi « connexion fraîche » est une meilleure expression opérationnelle que « serveur vierge ». Le helper est nouveau. Le serveur ne l'est pas.

Supposons qu'un agent exécute une vérification de déploiement, puis se termine après qu'une personne chargée de la revue a rejeté la modification suivante. Si la première exécution a laissé une socket de multiplexage, un autre processus sur la même machine peut se connecter à un canal déjà authentifié. Le processus suivant a franchi une frontière de sécurité que les opérateurs pensaient appliquer à chaque exécution. Avec un helper stateless, ce deuxième processus doit demander une nouvelle action et repasser par le chemin d'autorisation prévu.

L'avantage relève en partie de la sécurité et en partie du diagnostic. Lorsqu'une personne chargée d'examiner un incident voit une connexion partagée restée active pendant des heures, elle doit reconstituer lesquels de plusieurs processus l'ont utilisée. Lorsque chaque demande possède son propre cycle de vie de connexion, l'enregistrement a un début et une fin naturels.

Le partage de connexion entre en conflit avec l'attribution par exécution

OpenSSH prend délibérément en charge le partage de connexions. Le manuel de ssh_config décrit ControlMaster comme une option qui permet à plusieurs sessions de partager une même connexion réseau. ControlPersist peut garder la connexion maître ouverte en arrière-plan après la fermeture des clients. Ces options sont utiles pour un administrateur qui exécute plusieurs commandes depuis un même terminal. Elles constituent un mauvais choix par défaut pour des exécutions d'agents qui nécessitent une autorité et des enregistrements distincts.

Considérez cette configuration courante :

Host build-box
  HostName 10.0.0.24
  User deploy
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 15m

La première invocation de SSH crée une socket maître authentifiée sous ~/.ssh. Les invocations suivantes qui peuvent accéder à cette socket peuvent réutiliser sa connexion pendant la fenêtre de persistance de quinze minutes. Un processus d'agent lancé après la fin du processus initial peut donner l'impression d'avoir établi une connexion indépendante dans sa propre transcription, alors qu'il a en réalité utilisé un transport créé plus tôt.

Cela crée quatre problèmes distincts.

Premièrement, le sens de l'approbation dérive. Si une personne a approuvé un processus d'agent donné pour exécuter une vérification, cette approbation ne devrait pas automatiquement couvrir un nouveau processus qui trouve par hasard la même socket.

Deuxièmement, l'identité de la destination devient plus difficile à vérifier au bon moment. La vérification de l'hôte SSH a lieu lorsque la connexion maître est créée. Les clients suivants héritent de ce résultat. Pour savoir quelle vérification a eu lieu, une personne chargée de la revue d'un appel ultérieur doit retrouver un événement de connexion plus ancien.

Troisièmement, les journaux perdent une relation simple entre une demande et un transport. Un journal classique du serveur SSH peut enregistrer une seule connexion, tandis que les enregistrements au niveau de l'application montrent de nombreuses commandes. Les deux peuvent être exacts, mais leur rapprochement demande du travail au moment même où personne n'a de temps à perdre.

Quatrièmement, la socket devient un actif. OpenSSH précise dans ssh_config que toute personne capable d'accéder à la socket de contrôle peut accéder à la connexion. Les permissions de fichiers aident, mais elles ne rendent pas un canal authentifié partagé adapté à un espace de travail hostile ou simplement confus.

Désactivez le multiplexage pour les appels qui nécessitent une attribution claire. Une invocation directe rend ce choix explicite :

ssh -o ControlMaster=no -o ControlPath=none deploy@build-box 'id; hostname'

La sortie attendue a par exemple cette forme :

uid=1004(deploy) gid=1004(deploy) groups=1004(deploy)
build-box

La commande prouve seulement quel compte et quel hôte ont répondu. Elle ne prouve ni que le compte disposait de droits appropriés, ni que la tâche demandée était sûre. Elle donne néanmoins à la personne chargée de la revue une action à associer à une tentative de connexion.

Ne prenez pas l'absence de ligne ControlMaster pour une solution complète. Une configuration SSH globale peut la définir, un wrapper peut l'ajouter et un processus peut pointer ControlPath vers un emplacement inattendu. La frontière d'exécution doit définir elle-même ses options SSH au lieu de faire confiance aux fichiers de configuration du dépôt.

Chaque exécution d'agent a besoin de sa propre frontière d'autorité

Une exécution d'agent n'est pas une session de terminal humain avec un dactylographe plus rapide. L'agent peut recevoir de nouvelles instructions dans des tickets, des pull requests, des sorties de tests générées, des extraits de journaux copiés et des fichiers source qu'il n'a pas écrits. N'importe lequel de ces contenus peut l'orienter vers des commandes qui ne faisaient pas partie de l'intention initiale.

Cela change le sens des fonctions de confort. Une personne qui conserve une session sait généralement qu'elle la conserve. Un agent peut commencer une nouvelle tâche sans savoir qu'un ancien canal reste disponible. Son interface d'outil affiche souvent seulement « exécuter la commande », tandis que le client sous-jacent trouve silencieusement une socket et obtient l'autorité précédente.

Traitez le processus de l'agent comme l'unité qui reçoit l'approbation. Lorsqu'il se termine, son accès doit se terminer avec lui. Si un nouveau processus démarre, même s'il est lancé par le même éditeur ou le même orchestrateur, demandez une nouvelle décision d'autorisation avant de le laisser atteindre un hôte protégé.

Cette approche est plus stricte que ce que souhaitent de nombreux développeurs au départ. Ils voient se multiplier les approbations et se tournent vers une liste d'autorisation très large. Cela résout une gêne en supprimant la frontière utile. Une meilleure conception regroupe les actions liées dans une exécution explicite, accorde à cette exécution l'accès après qu'une personne a vérifié son identité, puis supprime cet accès à la fin de l'exécution.

L'identité issue de la signature du code compte ici, mais elle ne répond pas à toutes les questions. Elle peut indiquer quelle application signée a lancé le processus. Elle ne peut pas dire si cette application suit des instructions fiables ou si son dépôt actuel contient un prompt malveillant. L'approbation doit associer un processus connu à une période d'autorité limitée, et non valider toutes les instructions que ce processus lira un jour.

Une frontière claire gère aussi correctement les nouvelles tentatives. Une défaillance réseau peut déclencher une nouvelle demande. La passerelle doit consigner que la première action a échoué avant l'exécution ou pendant le transport, puis enregistrer la nouvelle tentative comme une autre action. Fusionner les tentatives dans un vague enregistrement de réussite supprime des informations dont les personnes chargées de répondre aux incidents ont besoin.

Le transfert de l'agent détruit la frontière des identifiants

Le transfert de l'agent SSH donne à un hôte distant un moyen de demander à votre agent d'authentification local de signer des défis. Il ne copie pas le fichier de clé privée sur cet hôte, mais cette distinction peut sembler plus rassurante qu'elle ne l'est réellement.

Le manuel OpenSSH de ssh avertit que les utilisateurs capables de contourner les permissions de fichiers sur l'hôte distant peuvent accéder à l'agent transféré. Un utilisateur root sur cet hôte peut utiliser la socket transférée pour s'authentifier ailleurs tant que la connexion reste ouverte. Il ne reçoit toujours pas le contenu de la clé privée, mais il peut utiliser l'autorité qu'elle représente. Pour un agent autonome, c'est généralement le risque que vous cherchiez à éviter.

Évitez les appels comme celui-ci :

ssh -A deploy@build-box 'git fetch && ./deploy.sh'

L'option -A transfère l'agent d'authentification local. Un script de déploiement qui atteint une deuxième machine peut alors amener l'hôte distant à demander des signatures via la socket transférée. Une machine de build compromise, ou un script modifié par un contributeur non fiable, obtient ainsi un chemin inattendu vers un autre environnement.

Utilisez plutôt un identifiant appartenant à la tâche de destination. Il peut s'agir d'un compte de déploiement associé à une clé publique restreinte, d'un certificat SSH de courte durée émis pour un environnement donné ou d'un compte de service distant qui ne peut récupérer que l'artefact nécessaire. Le mécanisme exact dépend de votre infrastructure. La règle reste la même : ne transformez pas l'action approuvée d'un agent en accès général à l'authentification depuis une machine distante.

Certaines équipes conservent le transfert parce que les connexions SSH imbriquées sont pratiques. Elles ont une bastion, puis se connectent à des hôtes privés. Utilisez ProxyJump ou un chemin de passerelle strictement contrôlé lorsque c'est possible. Ces approches laissent le client contrôler l'établissement de la connexion au lieu de placer une puissante socket d'agent local sur l'hôte intermédiaire.

La redirection de ports mérite la même méfiance. Les redirections locales, distantes et dynamiques peuvent transformer une commande approuvée en tunnel ouvert qui survit au travail utile de l'action. Un helper stateless devrait refuser les fonctions de redirection ou demander une approbation distincte, sauf si la tâche demandée en a précisément besoin.

Un compte distant précis limite les dégâts de mauvaises instructions

Un état local vierge n'aide pas lorsque la connexion distante peut tout faire. Le compte atteint par l'agent doit avoir une fonction définie et des permissions qui lui correspondent.

Sur un hôte de déploiement, il peut s'agir d'un compte capable de modifier un lien symbolique de version, de redémarrer un seul service et de lire un seul répertoire de déploiement. Il ne devrait pas avoir en plus des privilèges généraux sans mot de passe, accès au répertoire personnel de chaque utilisateur et permission de modifier le runner CI. Ces combinaisons apparaissent parce que quelqu'un voulait faire fonctionner une tâche d'automatisation avant le déjeuner. Elles restent en place parce que personne ne revient ensuite les réduire.

OpenSSH fournit aux administrateurs de serveurs plusieurs contrôles dans le format authorized_keys. Le manuel documente notamment des options comme command=, qui impose une commande lors de l'authentification de la clé, ainsi que des options qui désactivent la redirection de ports, la redirection X11 et le transfert de l'agent. Ces contrôles sont utiles lorsque la destination offre une petite surface de commandes stable.

Par exemple, une équipe d'exploitation peut associer une clé publique dédiée à un wrapper distant limité :

command="/usr/local/libexec/release-action",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAA... agent-release

La commande forcée doit analyser les arguments demandés avec prudence. Ne transmettez pas directement du texte fourni par l'utilisateur à un shell. Un wrapper sûr accepte un petit ensemble de verbes, vérifie que les identifiants de version respectent le format attendu, écrit un enregistrement d'audit et exécute l'opération fixe correspondante. Si l'agent a besoin d'un accès shell arbitraire, reconnaissez-le clairement et limitez suffisamment les permissions du compte pour contenir ce risque.

Une commande forcée n'est pas un langage de politique généraliste. C'est une interface volontairement réduite sur un hôte. Cette contrainte fait sa force. Vous pouvez la tester, la relire et déterminer quelles actions elle peut réaliser sans interpréter un ensemble de règles en langage naturel.

Soyez prudent avec sudo. Une ligne qui autorise un script peut tout de même donner un accès étendu si le script accepte des chemins arbitraires, charge sa configuration depuis un répertoire accessible en écriture, lance un éditeur ou appelle un autre programme via une variable d'environnement contrôlée par l'utilisateur. Examinez toute la chaîne d'appels. La ligne de permission marque le début de la revue, pas sa fin.

L'enregistrement de l'action doit répondre à qui, quoi, où et résultat

Un journal d'audit utile ne se contente pas d'indiquer que SSH a été utilisé. Il doit permettre à une personne de reconstituer une action sans deviner quelle exécution d'agent en était responsable.

Consignez l'identifiant d'exécution de l'agent, son autorité de processus, la décision de la personne chargée de la revue, la destination, le compte distant, la commande ou l'opération demandée, l'heure, le résultat et une référence vers la sortie. Enregistrez l'identité d'hôte résolue lorsque votre conception permet de l'exposer. Consignez également les refus. Une action refusée prouve que la frontière a fonctionné comme prévu et peut révéler une mauvaise instruction avant qu'elle ne cause des dégâts.

Les commandes exigent une attention particulière. Une commande brute peut contenir des mots de passe, des jetons d'accès, des valeurs de requête et des chemins privés. Tout masquer rend l'enregistrement inutile, mais tout conserver peut transformer le journal en nouveau coffre à secrets. La réponse pratique consiste à concevoir l'interface d'action de façon que les valeurs sensibles n'apparaissent pas dans les arguments. Lorsqu'une suppression est nécessaire, consignez à la fois l'événement de suppression et suffisamment de contexte structuré pour identifier l'opération.

La sortie pose le même problème. Une erreur de commande de déploiement peut afficher une variable d'environnement ou une URL contenant un identifiant. Conservez la sortie séparément de l'événement principal, limitez les personnes qui peuvent la lire et traitez-la comme une entrée potentiellement sensible pour la prochaine exécution de l'agent. Ne renvoyez pas automatiquement une transcription complète de production à un agent simplement parce qu'il demande à diagnostiquer un échec.

Il faut aussi garder une autre distinction nette : un journal indiquant qu'un agent a demandé une action ne prouve pas que l'action a atteint l'hôte distant. Les échecs de transport, le rejet de la clé d'hôte, l'échec de l'authentification distante, le statut de sortie de la commande et les pertes de connexion sont des résultats différents. Un bon enregistrement donne à chacun son propre statut au lieu de les ranger tous sous « échec ».

La preuve d'intégrité modifie le modèle de confiance dans l'enregistrement. Un journal dont les entrées sont chaînées par hachage peut montrer que des entrées ont été modifiées, supprimées ou réordonnées lorsque la vérification échoue. Il ne peut pas dire que la commande initiale était judicieuse et ne peut pas rendre honnête un terminal compromis. Il protège l'historique dont vous disposez, mais ne remplace pas le renforcement du système.

Un déploiement échoué montre l'intérêt d'un état local vierge

Imaginez qu'un agent de programmation reçoive une demande de déploiement d'une branche sur un hôte de staging. Son premier appel ouvre une connexion SSH, vérifie l'espace disque et démarre une commande de version. La commande échoue parce qu'un verrou de migration existe. L'agent voit l'échec, lit les notes du dépôt et reçoit un message copié qui lui dit de « supprimer le verrou et réessayer avec le compte d'urgence ».

Ce message peut être une suggestion innocente mais dangereuse, ou une injection de prompt cachée dans un fichier que l'agent devait examiner. Dans les deux cas, l'agent propose maintenant une commande qui sort de la routine de déploiement initiale.

Avec une connexion partagée de longue durée, plusieurs choses peuvent mal tourner. Le transport initial peut encore authentifier un compte de déploiement très puissant. Un nouveau processus peut le réutiliser. La personne chargée de la revue ne voit que la première approbation de connexion et peut ne pas distinguer clairement l'escalade ultérieure. Si la configuration transférait aussi un agent SSH, l'hôte de staging peut disposer d'un moyen d'utiliser une autre identité.

Avec un helper stateless et une autorisation par exécution, l'appel suivant de l'agent commence comme une nouvelle demande. La frontière identifie le nouveau processus d'agent, consigne la commande et la cible réellement proposées, puis demande une approbation si l'exécution n'est pas déjà approuvée. La personne chargée de la revue peut refuser la demande de compte d'urgence et approuver à la place une opération limitée qui inspecte le propriétaire du verrou.

La fraîcheur de la connexion n'a pas permis de décider que la suppression du verrou était dangereuse. Les humains doivent toujours évaluer les opérations. Elle a empêché un ancien canal approuvé de rendre cette décision discrètement inutile.

C'est pourquoi une conception SSH stateless doit accompagner, et non remplacer, des contraintes raisonnables sur les commandes. L'isolation de la connexion limite l'autorité locale héritée. Une interface distante restreinte limite ce qu'une nouvelle connexion peut faire. Les journaux d'audit permettent ensuite de comprendre ces deux décisions.

L'exécution stateless exige une conception opérationnelle explicite

Un helper qui ouvre une connexion pour chaque demande doit définir clairement son comportement concernant la vérification de l'hôte, les délais d'attente, l'annulation et le signalement des échecs. Laisser ces détails dépendre de ce que l'environnement de l'agent fournit par hasard recrée un état caché sous un autre nom.

Vérifiez les clés d'hôte. Dans OpenSSH, StrictHostKeyChecking=yes indique au client de refuser les hôtes dont la clé est inconnue ou a changé, au lieu de poser une question interactive. C'est normalement le comportement approprié pour une action automatisée protégée. Distribuez les clés d'hôte approuvées par un processus contrôlé, puis échouez de manière fermée si la destination ne correspond pas.

Utilisez des délais d'attente limités. Une connexion SSH bloquée doit finir par renvoyer un échec consigné, et non rester disponible indéfiniment comme une session à moitié terminée. Le helper doit aussi terminer les processus enfants lors d'une annulation lorsque le système d'exploitation le permet, et indiquer s'il peut confirmer cette terminaison. Ne signalez pas qu'une commande distante a été annulée lorsque le transport s'est interrompu après que le serveur l'a déjà démarrée.

Gardez une forme de demande réduite et facile à inspecter. Une frontière d'action peut représenter une demande SSH avec des champs structurés comme la destination, le compte, la commande, le répertoire de travail s'il est pris en charge et le délai d'attente. Elle ne devrait pas accepter un bloc de configuration shell capable de modifier les fichiers d'identité, le comportement du proxy, les chemins de sockets de contrôle et les options de transfert sans revue.

Une passerelle peut conserver l'identifiant SSH pendant que l'agent demande une action. Sallyport suit ce modèle pour SSH avec son helper stateless sp-ssh intégré : l'agent ne reçoit pas la clé SSH et l'app exécute elle-même l'action.

La frontière doit également distinguer une approbation de session d'une approbation par appel. L'approbation de session convient à une exécution d'agent délimitée, lorsqu'une personne accepte une séquence de tâches attendues. L'approbation par appel convient aux identifiants ou aux destinations pour lesquels chaque utilisation mérite une décision humaine distincte. Ne prétendez pas que ces choix offrent le même contrôle. Ils échangent volontairement le nombre d'interruptions contre le niveau de détail.

Testez la réutilisation cachée avant de faire confiance à la frontière

Vous pouvez vérifier que votre configuration crée réellement des connexions indépendantes. Faites-le dans un environnement hors production, avec un compte qui ne possède aucun accès sensible.

Commencez par lancer deux processus d'agent ou de helper distincts qui exécutent chacun une commande inoffensive comme id. Consultez le journal d'authentification du serveur SSH et votre journal d'actions. Vous devriez voir deux tentatives de connexion que vous pouvez associer à deux enregistrements de processus distincts.

Inspectez ensuite le côté client à la recherche de sockets de multiplexage. Sur macOS et les systèmes de type Linux, une inspection générale peut ressembler à ceci :

find ~/.ssh -type s -print

Si un chemin correspondant à une socket de contrôle apparaît, déterminez quelle configuration l'a créée. Ne supprimez pas une socket aveuglément sur une machine partagée. Trouvez d'abord son propriétaire et ses clients actifs. Supprimez les paramètres de partage de connexion du chemin d'exécution du helper isolé au lieu de compter sur un nettoyage ultérieur.

Enfin, exécutez une action approuvée, terminez le processus de l'agent, puis lancez un deuxième processus. Le second processus ne doit pas hériter de l'autorisation, du transport d'authentification ou de la possibilité d'ouvrir un shell distant du premier sans nouvelle décision. Testez le chemin refusé avec autant de soin que le chemin approuvé. Les équipes découvrent souvent que le parcours normal est isolé alors qu'un gestionnaire d'erreur revient à une commande SSH directe.

Cette dernière vérification détecte un échec bien connu : une passerelle prudente gère les demandes normales, mais un script de nouvelle tentative ou un outil de diagnostic la contourne lorsque la pression monte. Le contournement est généralement ajouté par quelqu'un qui cherche à rétablir rapidement le service. Il devient ensuite le chemin que l'agent trouve lorsque sa première tentative échoue.

Un état local vierge pour chaque action SSH n'est pas une formalité. Il donne au travail autonome une frontière que les personnes peuvent inspecter, approuver, révoquer et examiner. Gardez le compte distant limité, refusez les identifiants transférés, consignez précisément les résultats et faites gagner son propre accès à chaque nouveau processus d'agent.