# Accès SSH via proxy
SUMMARY: Comment un agent LLM exécute des commandes sur des machines distantes en toute sécurité via une API de proxy SSH au lieu de clés SSH brutes.

KEY CONTEXT:
Ne garde JAMAIS de clés privées SSH brutes en tant que LLM. Utilise une API HTTP de proxy SSH :
1) POST /connect?target=<name> → session_id (persistante, survit des heures).
2) POST /<session_id>/exec {command, timeout} → exec_id.
3) GET /<session_id>/exec/<exec_id> → sortie quand c'est fini.
4) Utilise les endpoints SFTP pour l'upload/download de fichiers au lieu de cat/heredoc.
Les targets sont des noms pré-enregistrés (ex. "vps1"), pas des IPs — le proxy est
le seul endroit où vivent les identifiants.

Accès SSH via proxy
Les agents doivent exécuter des commandes sur des machines distantes — déployer un conteneur, lire un log, corriger une config. Remettre des clés privées SSH brutes à un LLM est une mauvaise idée : les clés finissent dans les fenêtres de contexte, les logs et les transcriptions. Un proxy SSH résout cela : il détient les identifiants, l'agent ne parle qu'en HTTP.
Le modèle
[CODE BLOCK]
Le proxy expose des sessions persistantes avec une surface REST simple :
| Endpoint | Objectif |
|---|---|
|  | ouvrir une session →  |
|   | exécuter une commande (async) →  |
|  | interroger la sortie |
| Endpoints SFTP | up/download de fichiers, , ,  |
L'authentification est un token Bearer — le même motif que toutes les autres API que tu utilises.
Le motif d'exécution
[CODE BLOCK]
Règles d'engagement
1. Réutilise les sessions. Se connecter par commande gaspille des ressources et déclenche les limites de débit. Stocke le  (ex. ) et fais-lui un heartbeat avant réutilisation.
2. Nomme les targets, ne les découvre pas. Les targets sont pré-enregistrés (, , …). Le proxy est la source unique de vérité — n'intègre jamais d'adresses IP en dur dans le code d'agent.
3. Préfère SFTP à cat/heredoc de shell pour les fichiers. Échapper des données binaires via  corrompt les payloads. Utilise les endpoints dédiés d'upload/download.
4. Cite tes commandes. Le corps JSON est parsé deux fois (HTTP + shell). Enveloppe les commandes distantes dans des guillemets simples et garde-les sur une ligne.
5. Suppose l'audit. Chaque exec atterrit dans le journal d'audit du proxy — comporte-toi comme si l'humain lisait tout (il peut).
Quand NE PAS utiliser exec
- Lire un état structuré qui a une API (Docker, bases de données, la Mind API de Synapse) — préfère toujours l'API au parsing de sortie CLI.
- Processus interactifs de longue durée.  est fire-and-forget avec timeout ; utilise  + un fichier d'état sur la cible.
- Tout ce qui est destructif sans instruction explicite. Le proxy te donne le pouvoir — l'humain te donne la permission.
Récupération d'erreurs
| Symptôme | Solution |
|---|---|
| 401 au connect | token expiré — relis-le depuis memory/settings, jamais depuis une transcription |
| session 404 | session expirée (plafond 24h) — reconnecte-toi |
| timeout d'exec | augmente  ou découpe la commande ; vérifie la charge de la cible |
| contenu de fichier corrompu | tu as utilisé  au lieu de SFTP — passe aux endpoints SFTP |