Backend SSH Hermes : isoler l’exécution quand le poste principal ne doit pas être touché
Tu configures un agent IA sur ta machine. Tu lui donnes accès au terminal, aux fichiers, à des commandes système. Jusque-là, tout va bien. Mais à un moment, tu te poses la question : est-ce que j’ai envie qu’un agent puisse toucher à mon code source, mes dossiers personnels ou ma configuration système si quelque chose dérape ?
La réponse est souvent non. Et c’est là que le backend SSH de Hermes Agent devient utile.
Le risque d’exécuter un agent sur sa machine principale
Par défaut, Hermes Agent exécute les commandes terminal en local. C’est pratique pour du développement rapide, des tests ou des tâches où tu supervises chaque étape. Mais le mode local a une conséquence directe : l’agent a accès à tout ce que ton utilisateur peut faire.
Le vrai sujet n’est pas d’ajouter un agent de plus.
Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.
Arbitrages utiles
Questions réelles
Accès gratuit
Tu arrives avec ton sujet, tu repars avec plus de clarté.
Ça inclut tes projets en cours, tes fichiers de configuration, tes clés SSH, tes dossiers personnels. Si l’agent interprète mal une instruction, si un prompt est ambigu ou si une tâche automatique part dans une direction imprévue, les dégâts peuvent être réels. Fichiers modifiés, paquets installés sans contrôle, variables d’environnement altérées.
Ce n’est pas une question de confiance aveugle dans l’agent. C’est une question de surface d’exposition. Plus l’agent a de portes ouvertes, plus le risque de conséquence non voulue augmente.
La séparation par SSH : ce que ça change concrètement
Le backend SSH de Hermes Agent déplace l’exécution des commandes sur une machine distante. Au lieu de lancer terminal sur ton poste principal, l’agent se connecte en SSH à un serveur dédié et exécute tout là-bas.
La documentation de Hermes le présente comme une option « recommandée pour la sécurité — l’agent ne peut pas modifier son propre code ». C’est le point central : ton installation Hermes, ses fichiers de configuration, ses skills et ses profils restent sur ta machine. L’agent travaille ailleurs.
Voici ce que ça change en pratique :
| Critère | Backend local | Backend SSH |
|---|---|---|
| Où les commandes s’exécutent | Sur ton poste principal | Sur un serveur distant |
| Accès au code source Hermes | Oui, complet | Non, l’agent est isolé |
| Fichiers personnels exposés | Tout ce que ton utilisateur voit | Uniquement ce qui est sur le serveur distant |
| Installation de paquets | Impacte ta machine | Impacte le serveur distant |
| Configuration nécessaire | Aucune, c’est le défaut | Clé SSH, hôte, utilisateur |
La séparation est nette : ton poste reste ton poste. Le serveur distant devient le bac à sable de l’agent.
Les pré-requis pour activer le backend SSH
La configuration est simple. Trois variables dans le fichier ~/.hermes/.env suffisent :
TERMINAL_SSH_HOST: l’adresse du serveur distant (IP ou nom de domaine)TERMINAL_SSH_USER: l’utilisateur SSH sur ce serveurTERMINAL_SSH_KEY: le chemin vers ta clé privée SSH
Ensuite, tu actives le backend dans ~/.hermes/config.yaml :
terminal:
backend: sshÀ partir de là, chaque appel à l’outil terminal passe par SSH. L’agent ne voit plus ton système de fichiers local. Il voit celui du serveur distant.
Un point important : le serveur distant doit être préparé. L’utilisateur SSH doit avoir les droits nécessaires pour exécuter les commandes dont l’agent a besoin. Si tu veux que l’agent installe des paquets, il faut que l’utilisateur ait les permissions correspondantes. Si tu veux limiter ce qu’il peut faire, tu peux restreindre ces permissions.
Tester que l’isolation fonctionne
Une fois la configuration en place, vérifie que tout fonctionne avant de lancer des tâches complexes.
Commence par un test simple : demande à l’agent d’exécuter whoami et hostname. Les réponses doivent correspondre à l’utilisateur et au serveur distant, pas à ta machine locale.
Ensuite, teste un accès fichier : demande à l’agent de lister le contenu de /home sur le serveur. Il doit voir les dossiers du serveur distant, pas les tiens.
Enfin, vérifie que l’agent ne peut pas accéder à tes fichiers locaux : demande-lui de lire un fichier qui existe sur ta machine mais pas sur le serveur. Il doit échouer.
Si ces trois tests passent, l’isolation est effective.
Ce que le backend SSH ne protège pas
En résumé : le backend SSH répond à la question « où l’agent exécute-t-il ses commandes ? ». Il ne répond pas à « qui peut faire quoi sur le réseau ? » ni à « où vont les données ? ». Ce sont des couches de sécurité différentes, qui se complètent mais ne se remplacent pas.
Vérifier son hôte distant avant de l’utiliser
Avant de connecter un agent à un serveur, prends le temps de vérifier l’état de ce serveur.
Regarde les utilisateurs qui ont accès, les clés SSH autorisées, les services qui tournent, les ports ouverts. Un serveur mal configuré peut transformer ton isolation en passoire.
Si tu utilises déjà Hermes Agent pour automatiser des tâches business, la question de l’isolation devient encore plus concrète. Un agent qui tourne sur un serveur dédié, avec des permissions limitées et un accès réseau contrôlé, c’est un setup qui réduit les risques sans ralentir le travail.
Tu peux faire une demande d’audit de ta configuration sur la page de la formation Hermes Agent. On y voit comment structurer l’exécution des agents pour qu’ils travaillent sans toucher à ce qui ne doit pas être touché.
