Enregistrez vos connexions SSH,
lancez vos agents IA sur la machine distante

Comment mes agents IA peuvent-ils accéder à mes connexions SSH ?

Via AgentsRoom MCP. Vos connexions enregistrées sont exposées à chaque agent sous forme de cinq outils MCP : ssh_list renvoie les serveurs utilisables dans le projet courant (SSH, AWS SSM et WinRM confondus), ssh_exec exécute une commande sur un serveur et en renvoie la sortie (une ligne PowerShell sur un hôte WinRM, en lecture seule sauf si vous autorisez les écritures, que vous confirmez une par une, seulement quand elles sont risquées ou jamais, à votre choix), ssh_transfer déplace un fichier vers ou depuis un serveur, ssh_connect en ouvre un dans un vrai onglet de terminal, et ssh_connection_new propose un serveur que vous n’avez pas encore enregistré. Quand vous dites à un agent "connecte-toi à la prod et lis les logs" ou "liste les connecteurs d’envoi Exchange", il n’a donc ni nom d’hôte à deviner ni commande à écrire à la main : il lit votre liste de connexions et travaille sur la bonne machine.

Cet accès SSH des agents est volontairement sans secret. ssh_list ne renvoie que des métadonnées : nom, hôte, port, utilisateur, type d'authentification et portée. Les mots de passe et passphrases restent chiffrés dans le trousseau de votre système, les clés privées restent sur votre disque, et c'est l'application qui injecte le secret dans le terminal. L'agent nomme une connexion, il ne la manipule jamais.

Une session ouverte par un agent avec ssh_connect est un onglet de terminal visible : vous le lisez, vous y tapez, vous le fermez quand vous voulez. Et une commande lancée avec ssh_exec revient dans sa conversation avec son code de retour, donc vous voyez toujours ce qui a été exécuté et ce que la machine a répondu. Les fichiers voyagent de la même façon : avec ssh_transfer, un agent récupère un dump ou un log depuis un serveur, ou y pousse un fichier, via ce même canal sans identifiant, et récupère un chemin sur votre machine plutôt que le fichier collé dans sa conversation. Une connexion peut être enregistrée pour un seul projet ou en global, pour qu'un agent ne voie que les serveurs pertinents. Les équipements réseau dont la ligne de commande ne fonctionne que dans une session ouverte, comme un pare-feu WatchGuard ou beaucoup de switchs et de routeurs, sont aussi couverts : ssh_exec ouvre la session, attend l'invite de l'équipement et tape les commandes l'une après l'autre.

Pendant qu'un agent travaille sur un serveur, vous le suivez en direct. Chaque commande qu'il lance avec ssh_exec défile dans l'onglet Activité du panneau de droite, sortie comprise, dans un journal par serveur ; l'avatar de l'agent apparaît sur le bouton Serveurs et, avec un badge Agent au travail, dans votre liste de serveurs. Une commande envoyée encodée s'affiche décodée. Vous pouvez aussi le suivre depuis votre téléphone, dans la fiche de l'agent de l'app mobile. Tout ne circule qu'entre votre ordinateur et votre téléphone, chiffré de bout en bout et secrets masqués : rien de ce qui tourne sur vos machines n'est stocké sur un serveur.

Créer peut aussi être entièrement le travail de l'agent. ssh_connection_new garde le chemin relu : il ouvre le formulaire de création pré-rempli avec ce que l'agent a trouvé dans un fichier compose, un script de déploiement ou votre documentation, et c'est vous qui relisez, qui tapez l'identifiant et qui enregistrez. Sauf si vous désactivez "Les agents peuvent gérer les connexions" (Paramètres, activé par défaut), ssh_connection_save écrit la connexion directement, et même alors l'identifiant ne transite jamais par la conversation : l'agent nomme un secret de votre coffre et l'application desktop le copie. L'interrupteur est écrit dans le réglage plutôt que demandé dans un prompt, parce qu'une connexion qu'un agent pourrait enregistrer sans être vu serait une porte dérobée.