# Accès SSH des agents IA : commandes distantes sans clés privées Donner une clé privée SSH à un agent de programmation IA est une mauvaise abstraction. L’agent n’a pas besoin d’un identifiant permanent capable de s’authentifier depuis n’importe quelle machine, à n’importe quel moment. Il a besoin de l’autorisation d’effectuer une action distante précise, tout en vous laissant voir, arrêter et expliquer cette action. Cela peut sembler être une petite modification d’architecture. Ce n’en est pas une. Elle sépare un secret qui peut voyager indéfiniment d’une requête SSH qui possède un appelant, une destination, une commande, un résultat et un responsable. J’ai vu des équipes passer des jours à renforcer les règles de prompt autour d’un agent, puis laisser `~/.ssh/id_ed25519` lisible par le même processus. Les règles de prompt ne sont plus qu’un décor dès que la clé privée est disponible. Une commande shell peut copier le fichier, l’afficher, l’archiver ou l’envoyer quelque part où vous ne le découvrirez pas avant plusieurs semaines. Une clé privée n’est pas un jeton d’API auquel on aurait donné un nom plus court. C’est un jeton d’autorité réutilisable pour chaque serveur SSH qui accepte sa partie publique. ## Donnez à l’agent une action, pas une identité Un agent devrait demander une opération SSH, tandis qu’un composant de confiance distinct conserve l’identité et établit la connexion. Ce composant reçoit des données structurées, par exemple une destination, un compte distant, une commande, des arguments et un délai d’expiration. Il vérifie la demande, s’authentifie auprès du serveur, capture le résultat et ne renvoie que ce résultat à l’agent. Le secret reste sur une seule machine. Plus important encore, le droit de l’utiliser ne suit plus le processus de l’agent partout où il va. Cette distinction modifie le mode de défaillance. Si un agent est compromis ou suit des instructions hostiles provenant d’un dépôt, il peut toujours demander une mauvaise commande. En revanche, il ne peut pas exporter discrètement la clé privée pour la réutiliser depuis une VM éphémère le mois suivant. Vous transformez un problème ouvert de vol d’identifiants en problème d’autorisation et de contrôle des commandes. Le second problème mérite toujours toute votre attention. Il s’agit simplement d’un problème que vous pouvez exploiter et encadrer. Une forme de requête utile est volontairement peu spectaculaire : ```json { "host": "deploy-01.internal.example", "user": "release", "command": "/usr/local/libexec/release-service", "args": ["api", "2025.03.08-4f2c1a7"], "timeout_seconds": 120 } ``` Ne faites pas transiter une chaîne shell comme `ssh deploy-01 'cd /srv/api && git pull && sudo systemctl restart api'` par cinq couches en appelant cela un contrôle. Les règles d’interprétation du shell deviennent alors une partie de votre périmètre de sécurité, et presque personne ne les examine comme telles. Gardez le chemin de commande fixe, transmettez les arguments comme des valeurs séparées et faites rejeter par le wrapper distant les valeurs qui sortent de sa grammaire attendue. Je préfère un contrat d’action légèrement contraignant à utiliser plutôt qu’un terminal distant flexible que personne ne peut limiter. La contrainte apparaît lors de la configuration. Les dégâts d’un terminal sans restriction apparaissent plus tard. Le courtier doit renvoyer un résultat suffisamment structuré pour que l’agent puisse poursuivre son travail sans deviner : ```json { "exit_code": 0, "stdout": "released api version 2025.03.08-4f2c1a7\n", "stderr": "", "duration_ms": 1842 } ``` Ne renvoyez pas d’identifiants, de sockets d’agent, de contenu de `known_hosts` ni de TTY interactif. Ce sont des détails d’implémentation du côté de confiance. ## Possession, signature et exécution sont trois pouvoirs différents Les équipes parlent souvent d’« accès SSH » comme s’il s’agissait d’une seule chose. Cela recouvre au moins trois pouvoirs très différents : posséder une clé privée, demander à un agent de créer une signature et faire exécuter par un courtier une commande distante nommée. La possession d’une clé privée est le pouvoir le plus large. Quiconque lit le fichier peut le copier indéfiniment et l’essayer sur tous les serveurs accessibles. Les permissions de fichier, le chiffrement du disque et les phrases secrètes sont utiles, mais aucune de ces mesures ne répond à la question centrale : pourquoi un processus d’IA avait-il besoin d’un identifiant transportable ? Un `ssh-agent` évite que chaque client lise un fichier de clé privée. Le processus peut demander une signature via `SSH_AUTH_SOCK`. C’est une amélioration pour l’hygiène d’un poste local, mais la signature conserve le pouvoir d’authentification. Le manuel OpenSSH `ssh-agent(1)` indique que l’agent garde les clés privées hors du trafic réseau pendant la redirection, tandis que le demandeur redirigé reçoit le résultat des opérations d’identité. C’est une propriété utile, pas un modèle complet d’autorisation. L’exécution d’actions est plus limitée si vous la concevez ainsi. Un courtier peut refuser un hôte inconnu, interdire un autre compte distant, exiger une décision humaine, plafonner le temps d’exécution, refuser un TTY et conserver une trace de l’appel. Il peut aussi utiliser une identité SSH différente pour chaque catégorie d’opération. Ce dernier point compte davantage que ne le pensent les équipes. Une seule identité capable de lire les journaux, de déployer du code, de modifier `/etc/sudoers` et d’ouvrir des tunnels crée un périmètre d’autorisation aussi vaste que toute votre flotte. Quatre identités soumises à des restrictions étroites côté serveur créent quatre problèmes plus petits. Je préfère faire tourner quatre identités limitées après une erreur plutôt que de passer un week-end à prouver qu’une identité d’administrateur n’a atteint aucun hôte. Ce modèle ne rend pas une commande dangereuse inoffensive. Il vous donne des points où la détecter : avant la connexion, lors de l’authentification du serveur, dans la commande distante forcée et dans l’enregistrement final. ## La redirection de l’agent SSH répond à un autre problème La redirection de l’agent SSH évite de copier une clé privée sur un serveur bastion, mais elle ne rend pas une machine distante suffisamment sûre pour être confiée à un agent. L’hôte distant reçoit l’accès à un socket capable de demander des opérations à votre agent d’authentification local. OpenSSH le dit clairement dans `ssh_config(5)` : la redirection de l’agent doit être activée avec prudence, car un utilisateur capable de contourner les permissions sur l’hôte distant peut utiliser l’agent local via la connexion redirigée. L’attaquant ne peut pas extraire les octets de la clé privée par cette interface, mais il peut demander aux identités chargées de s’authentifier. Cette réserve est encore plus importante avec les outils autonomes. Un agent peut se connecter à un hôte parce qu’une tâche lui a demandé d’examiner un journal. Une instruction malveillante dans un dépôt, un compte distant compromis ou une commande mal confinée peut ensuite trouver `SSH_AUTH_SOCK` et utiliser la capacité de signature redirigée. La clé privée reste techniquement secrète, tandis que l’autorité d’authentification est détournée. Cette distinction ne réconfortera guère la victime. N’activez pas `ForwardAgent yes` globalement. Ajoutez `ForwardAgent no` à votre configuration client de référence et créez une exception explicite uniquement pour un parcours humain identifié qui en a réellement besoin. ```sshconfig Host * ForwardAgent no AddKeysToAgent no IdentitiesOnly yes StrictHostKeyChecking yes Host legacy-bastion HostName bastion.internal.example User ops ForwardAgent yes ``` L’exception ci-dessus nécessite encore une raison, un responsable et une date de suppression. Une exception permanente de redirection devient facilement invisible parce que SSH la rend si fluide. Les identités limitées à certaines destinations améliorent la situation, mais ne remplacent pas une limite d’action. Le manuel OpenSSH `ssh-add(1)` explique que les contraintes de destination vérifient l’ensemble du chemin de connexion lorsqu’un client et un serveur coopérants redirigent l’agent. Il avertit aussi qu’une personne disposant d’un `SSH_AUTH_SOCK` distant peut rediriger ce socket à nouveau, même si son utilisation reste limitée aux destinations autorisées. Utilisez les contraintes de destination lorsqu’elles sont adaptées. Ne les confondez pas avec une politique de commande. Elles indiquent où une identité peut s’authentifier, pas si `rm -rf /srv/release-cache` doit s’exécuter une fois arrivée. ## Suivez la défaillance tout au long du parcours de commande Un incident plausible commence par un raccourci bien intentionné : un développeur place une clé privée de déploiement dans une variable d’environnement parce que l’agent de programmation doit exécuter une seule commande de mise en production. L’agent lit ensuite dans une issue du dépôt une commande de diagnostic proposée. Cette commande affiche l’environnement pour faciliter le dépannage, puis le transcript d’exécution arrive dans le journal d’une session locale. La première perte s’est produite avant SSH. La clé privée est entrée dans un processus qui n’avait pas besoin de la conserver. L’agent dispose maintenant de plusieurs moyens de la divulguer ou de la réutiliser. Il peut écrire la valeur dans un fichier temporaire, l’envoyer à un hôte distant avec `scp`, la placer dans un commit Git ou la transmettre à un sous-processus situé en dehors des limites que vous aviez imaginées. Une clé privée copiée une fois n’expire pas simplement parce que vous avez arrêté cette exécution de l’agent. Supposons que l’équipe ait utilisé la redirection de l’agent. L’instruction du dépôt demande à l’agent de se connecter à `build-02`, puis d’exécuter une commande qui expose le socket redirigé à un processus local sur cette machine distante. L’attaquant ne peut pas afficher la clé privée, mais il peut demander au socket de s’authentifier auprès d’un autre hôte avec une identité chargée dans l’agent du développeur. La redirection n’avait jamais été conçue comme un mécanisme général de délégation, mais c’est devenu son rôle. Considérons maintenant une architecture avec courtier. L’agent envoie une demande pour `release-service api 2025.03.08-4f2c1a7` sur `deploy-01`. Le courtier constate qu’il s’agit de la première demande de ce nouveau processus d’agent et demande une autorisation. La personne qui l’approuve voit l’autorité de signature du processus appelant, l’identité distante et la cible. Le courtier ne se connecte qu’à l’hôte nommé. Le serveur n’accepte qu’une identité de déploiement restreinte et lance un seul wrapper côté serveur. L’instruction hostile peut toujours demander une mise en production. Elle ne peut pas transformer cette demande en shell de connexion, en redirection de port, en copie de clé privée ou en détour par des serveurs sans rapport. La réduction du rayon d’explosion est importante, mais elle vous coûte en flexibilité. Un agent généraliste peut improviser dans des situations de production inhabituelles. Une interface d’actions limitée ne le peut pas. Vous devrez ajouter des opérations réfléchies pour les journaux, l’état des services, les retours arrière, les contrôles de migration et le nettoyage des artefacts. Quelqu’un doit être responsable de ces interfaces. Ce travail n’est pas facultatif ; SSH sans restriction ne fait que le dissimuler. La bonne réponse consiste à faire couvrir au parcours sûr les tâches réellement effectuées, pas à rouvrir un shell brut chaque fois qu’il manque une fonction au parcours sûr. ## Placez le client SSH derrière un point de décision local Un point de décision local doit gérer trois choses : l’identité privée chiffrée, l’autorisation de l’utiliser et les preuves produites lorsqu’elle est utilisée. L’agent ne doit gérer aucune de ces trois choses. Sallyport suit ce modèle pour les agents macOS : son module `sp mcp` intégré accepte les appels MCP ordinaires, tandis que l’application de barre des menus conserve les identités SSH dans son coffre chiffré et utilise `sp-ssh` pour établir la connexion. L’agent reçoit le résultat de la commande, pas l’identifiant. La forme compte davantage que l’implémentation précise : ```text processus de l’agent IA -> demande d’action locale -> décision d’autorisation -> assistant SSH utilisant une identité protégée -> sshd distant et compte restreint -> stdout, stderr, statut de sortie ``` Gardez le point de décision sur la machine administrée du développeur lorsqu’une personne doit superviser le travail. N’en faites pas un proxy réseau qui signe silencieusement chaque demande de chaque processus. La limite de processus local permet d’attribuer l’appelant et de rejeter un exécutable inattendu avant toute connexion réseau. L’identité du processus n’est pas un champ décoratif dans une carte d’approbation. Une demande provenant de l’application signée attendue est différente d’une demande provenant d’un binaire non signé lancé depuis `/tmp`, même si les deux affirment être « l’agent de programmation ». Sur macOS, l’autorité de signature du code fournit à la personne qui approuve un élément concret à évaluer. Je veux qu’un nouveau processus obtienne une session avant de pouvoir utiliser une identité SSH. Je veux aussi que cette session disparaisse lorsque le processus se termine. Les autorisations longues sont faciles à exploiter et difficiles à expliquer après une compromission. Le verrouillage du coffre doit refuser toute action SSH. Aucun repli partiel ne doit permettre d’utiliser une clé privée mise en cache, un fichier PEM exporté ou un processus auxiliaire qui conserve sa propre copie cachée. Si votre procédure d’urgence contourne la protection, elle finira par devenir la procédure normale. ## Rendez le compte distant volontairement banal Le serveur distant doit limiter ce qu’une authentification SSH réussie peut faire. Une clé privée protégée ne constitue qu’une moitié du contrôle ; le serveur doit traiter cette identité comme conçue pour un usage précis, pas comme un compte d’administrateur humain. Créez un compte Unix distinct pour l’action, par exemple `release`, `diagnostics` ou `backup`. Ne lui donnez ni profil shell personnel, ni répertoire personnel étendu, ni connexion par mot de passe. Ne placez pas son identité publique à côté de celle, sans restriction, d’un ingénieur dans le même fichier `authorized_keys` en prétendant que les comptes sont séparés. Pour une opération de mise en production, une entrée `authorized_keys` peut ressembler à ceci : ```text restrict,command="/usr/local/libexec/release-service" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleOnlyReplaceThis release-broker ``` L’option `restrict` désactive la redirection de port, d’agent et de X11, l’allocation d’un pseudo-terminal et l’exécution de `~/.ssh/rc`. Le manuel OpenSSH `sshd(8)` documente précisément l’utilisation de `restrict` avec une commande forcée. La commande forcée ne doit pas transmettre la ligne de commande d’origine à `sh -c`. Elle devrait ignorer `SSH_ORIGINAL_COMMAND`, sauf si vous disposez d’un analyseur étroit et testé. Le wrapper doit accepter un protocole fixe, valider chaque champ, écrire une entrée d’audit et lancer l’opération réelle avec des limites explicites entre les arguments. Un petit wrapper shell convient s’il reste petit : ```sh #!/bin/sh set -eu service=${1:-} version=${2:-} case "$service" in api|worker) ;; *) echo "unsupported service" >&2; exit 64 ;; esac case "$version" in *[!0-9A-Za-z._-]*|"") echo "invalid version" >&2; exit 64 ;; esac exec /usr/bin/sudo /usr/local/sbin/deploy-approved-release "$service" "$version" ``` Appelez ce wrapper avec des arguments fixes depuis le courtier. Ne laissez pas le client choisir son chemin. Si vous avez besoin d’autres opérations, créez d’autres wrappers ou un petit répartiteur de commandes qui accepte des sous-commandes nommées et rejette tout le reste. C’est ici que je fixe une limite stricte : n’attachez pas un agent autonome à un compte partagé `ops` doté d’un shell normal en espérant compenser avec un meilleur prompt. Un compte shell partagé rend toutes les protections côté serveur facultatives. Pour les tâches avec état, utilisez des opérations idempotentes. Un wrapper de mise en production doit vérifier si l’artefact demandé est déjà actif, si le service est sain et si un point de retour existe avant de modifier quoi que ce soit. L’agent peut répéter une demande après un délai d’expiration ; votre opération distante ne doit pas interpréter cette répétition comme l’autorisation d’effectuer deux fois l’action. ## La vérification de l’hôte et la grammaire des commandes exigent la même rigueur Une identité privée protège l’authentification du client. Elle ne prouve pas que l’agent a atteint le serveur prévu. Si votre automatisation accepte toute nouvelle empreinte d’hôte, une erreur DNS, un fichier hosts empoisonné ou un attaquant actif sur le réseau peut rediriger la connexion vers un serveur qui recevra votre commande et en apprendra la sortie. Utilisez `StrictHostKeyChecking yes` pour les identités d’automatisation. Distribuez les empreintes d’hôte vérifiées par la gestion de configuration ou maintenez un fichier `known_hosts` soigneusement contrôlé. Lorsqu’un hôte renouvelle sa clé SSH, effectuez explicitement le changement avec une vérification hors bande. N’apprenez pas à l’agent à répondre « oui » à la demande de clé d’hôte. Un profil client minimal pour une action sans interaction ressemble souvent à ceci : ```sshconfig Host deploy-01.internal.example HostName deploy-01.internal.example User release IdentityAgent /path/to/broker.sock IdentitiesOnly yes StrictHostKeyChecking yes UserKnownHostsFile /Library/Application Support/agent-ssh/known_hosts BatchMode yes RequestTTY no ForwardAgent no ``` `IdentitiesOnly yes` empêche SSH d’envoyer à la destination toutes les identités disponibles via un agent. Cela réduit les tentatives d’authentification inutiles et évite l’utilisation accidentelle d’une identité personnelle lorsque celle prévue échoue. Le manuel OpenSSH `ssh_config(5)` le décrit comme un moyen d’utiliser les identités configurées plutôt que les identités supplémentaires proposées par un agent ou un fournisseur. Évitez de laisser l’agent choisir les noms d’hôte. Une demande devrait faire référence à une cible logique approuvée, comme `production-api-release`, et le côté de confiance devrait associer ce nom à un nom d’hôte, un compte distant, une empreinte, une identité et une famille de commandes. Cette table constitue une politique au sens courant, mais elle doit rester une donnée qu’une personne peut inspecter, pas un langage ingénieux qui encourage les failles. La grammaire des commandes mérite la même retenue. Autoriser des arguments arbitraires pour un binaire fixe peut tout de même conduire à une exécution arbitraire si le binaire accepte des chemins de fichiers, des noms de modules, des imports de configuration ou des options `--exec`. Examinez réellement l’interface en ligne de commande. Écrivez les jetons autorisés. Testez les entrées malformées, les espaces, les métacaractères shell, les surprises Unicode et les options répétées. Vingt minutes passées à malmener votre propre wrapper avec des arguments disgracieux vous apprendront davantage qu’une nouvelle demande d’approbation. ## Approuvez l’autorité au moment où elle devient utile L’approbation humaine doit intervenir à la limite où un processus obtient pour la première fois une capacité SSH, pas après chaque commande inoffensive et pas seulement après qu’une commande destructrice a déjà atteint le serveur. Une approbation par session constitue un choix pratique pour une exécution d’agent. La première action SSH tentée par un nouveau processus déclenche une décision. L’approbation doit indiquer quel processus signé l’a demandée, quelle identité il souhaite utiliser et quelle catégorie d’accès distant il recevra. Une fois approuvé, ce processus précis peut effectuer les demandes autorisées jusqu’à sa fermeture. Cela évite de transformer les diagnostics courants en une pile de clics. Cela évite aussi la pire solution : une approbation qui s’applique à tout processus futur nommé `node`, `python` ou `claude` sur la machine. Certaines identités méritent une seconde barrière à chaque utilisation. Les déploiements en production, les redémarrages d’urgence, les exports de bases de données, les modifications d’infrastructure et les commandes capables de modifier la connectivité réseau en sont de bons exemples. Le prix est l’interruption. Le bénéfice est qu’une session compromise ne peut pas utiliser discrètement l’identité la plus dangereuse après l’approbation d’un simple contrôle d’état. Sallyport peut imposer une approbation à chaque appel pour une identité SSH donnée, tandis que son autorisation de session habituelle associe l’autorisation à un processus d’agent précis. Son verrou de coffre refuse également les actions lorsque le coffre est verrouillé, au lieu de laisser un agent en arrière-plan continuer à fonctionner après le départ de la personne. La demande d’approbation ne doit pas demander aux utilisateurs de lire un paragraphe de JSON sérialisé. Affichez un résumé concis de l’action et rendez les détails accessibles : destination, compte distant, nom fixe de la commande, arguments fournis et délai d’expiration. Les humains repèrent vite `production-db` au lieu de `staging-db`. Ils ne repèrent pas de manière fiable un danger dans un long pipeline shell après la dixième demande. Un refus doit être un résultat à part entière. L’agent a besoin d’un résultat explicite pour signaler qu’il n’a pas l’autorisation, plutôt que de réessayer avec un autre compte, un autre hôte ou une solution de contournement. Les tentatives répétées après un refus doivent être enregistrées de façon visible. ## Un journal d’audit doit survivre à l’appelant compromis Les journaux produits par l’agent ne suffisent pas. Si le processus de l’agent peut écrire ou supprimer l’enregistrement de ses propres appels SSH, il peut laisser derrière lui la version agréable de l’histoire. Enregistrez l’activité en dehors du processus de l’agent. Au minimum, conservez l’identité du processus appelant, l’identifiant de session, l’heure, la destination, le compte distant, le nom de l’action, les arguments après application des règles de masquage, le résultat de l’autorisation, le code de retour, la durée et une capture limitée de stdout et stderr. Pour les commandes très verbeuses, capturez les 50 premières et les 50 dernières lignes, ou conservez un hachage du contenu avec l’artefact complet protégé lorsque la sortie peut contenir des secrets. N’enregistrez pas les clés privées brutes, les jetons porteurs ou les variables d’environnement arbitraires. Un système d’audit qui crée une seconde fuite d’identifiants est pire qu’un système d’audit absent, car les personnes lui feront confiance. L’authenticité des journaux modifie la façon dont vous enquêtez. Un journal chaîné peut révéler que quelqu’un a supprimé ou réordonné des entrées après coup, alors qu’un simple fichier texte en ajout seul prouve généralement seulement qu’un fichier existe. La vérification doit fonctionner sans exiger le déverrouillage du coffre ; sinon vous ne pourrez pas examiner les traces lorsque le système se trouve précisément dans l’état où vous en avez le plus besoin. Les recommandations de CISA sur les évaluations red team donnent une raison concrète de s’intéresser au confinement des identifiants. Son évaluation publiée décrit une équipe qui a obtenu des dizaines de clés privées SSH dans des fichiers accessibles et utilisé des identités privilégiées pour se déplacer entre des systèmes Linux. La leçon n’est pas que chaque agent deviendra un intrus. C’est que des éléments SSH réutilisables s’accumulent en inventaire de déplacement latéral lorsqu’ils atteignent des endroits qui n’en ont pas besoin. Lorsqu’une commande inattendue apparaît, révoquez d’abord la session de l’agent. Désactivez ensuite l’identité concernée sur le serveur, examinez l’activité vérifiée et consultez les journaux `sshd` et système de l’hôte cible. Faites tourner l’identité privée s’il existe la moindre chance qu’elle ait quitté le périmètre protégé. Un modèle avec courtier accélère cette séquence, car la révocation d’une session bloque les futures demandes d’action sans attendre qu’une clé privée copiée soit retrouvée. ## Utilisez quatre parcours étroits au lieu d’un shell généraliste Le déploiement pratique consiste à inventorier les actions distantes que vos agents tentent déjà et à les classer selon leurs conséquences. Ne commencez pas par demander de quelles clés privées ils ont besoin. Cette question part du mauvais endroit. La plupart des équipes trouvent un petit ensemble d’opérations récurrentes : - Lire l’état limité d’un service ou un extrait récent de journal. - Déployer un artefact déjà compilé dans un environnement. - Exécuter un contrôle de migration qui ne modifie pas les données. - Redémarrer un service nommé après une mise en production. - Collecter des diagnostics pour une tâche en échec. Créez un parcours d’action pour chacune. Attribuez un compte ou une identité distante dédiée lorsque les serveurs diffèrent. Forcez la commande côté serveur. Épinglez l’identité de l’hôte. Décidez si l’action nécessite une approbation de session ou à chaque utilisation. Enregistrez les appels autorisés comme les appels refusés. Conservez un parcours SSH humain pour les réparations inhabituelles. Pendant un incident, les humains ont parfois besoin d’un shell interactif, et prétendre le contraire les pousse vers des échappatoires dangereuses. Ce parcours doit utiliser une identité personnelle distincte, une MFA lorsque c’est possible, un bastion adapté et les contrôles habituels d’incident. Il ne doit pas partager l’identité d’automatisation simplement parce que cela économise une ligne dans `authorized_keys`. Le modèle plus sûr demande davantage d’ingénierie initiale : les wrappers doivent être testés, les empreintes d’hôte doivent avoir un responsable et votre catalogue d’actions doit être entretenu. Assumez ce coût. L’alternative consiste à donner à un générateur de texte probabiliste un identifiant capable de survivre à toutes les protections placées autour de sa tâche actuelle. Commencez par la clé privée SSH la plus proche de la production. Retirez-la de l’accès de l’agent, remplacez une commande shell générale par une action limitée et examinez le journal obtenu après une exécution réelle. Cette première limite vous montrera exactement où se cache le reste du travail.