Proposition: Connecteur SSH + Testeur d'Endpoints

Date: 26/01/2026 Status : IMPLEMENTEE Priorite: HAUTE Estimation: 2 phases

Contexte

L'utilisateur souhaite:

1. Un connecteur SSH intelligent pour executer des commandes sur des serveurs distants
2. Un testeur d'endpoints integre a chaque connecteur

Phase 1: Connecteur SSH

Concept

Un connecteur special qui permet d'executer des commandes sur des serveurs distants via SSH, avec gestion intelligente des credentials et logging complet.

Fonctionnalites

1.1 Creation d'instance SSH

Instance SSH:
- name: "Mon serveur prod"
- host: 192.168.1.10 ou serveur.domain.com
- port: 22 (defaut)
- username: gouroubleu
- auth_method: password | key | auto_key

1.2 Methodes d'authentification

Flow auto_key:

1. Generer paire RSA/ED25519 cote serveur connectors-api
2. Connexion initiale avec password
3. Ajouter la cle publique a ~/.ssh/authorized_keys du remote
4. Stocker la cle privee chiffree
5. Supprimer le password de la DB
6. Connexions futures = cle uniquement

1.3 API Endpoints

POST /api/ssh/execute
{
  "instance_id": "uuid",
  "command": "ls -la /var/log",
  "timeout": 30000,
  "cwd": "/home/user"  // optionnel
}

Response:
{
  "success": true,
  "stdout": "...",
  "stderr": "...",
  "exit_code": 0,
  "duration_ms": 234
}

POST /api/ssh/upload
{
  "instance_id": "uuid",
  "local_content": "base64...",
  "remote_path": "/tmp/script.sh",
  "mode": "755"
}

POST /api/ssh/download
{
  "instance_id": "uuid",
  "remote_path": "/var/log/app.log",
  "tail": 100  // optionnel, derniers N lignes
}

1.4 Audit / Logging

Chaque commande SSH est loggee:

{
  "instance_id": "uuid",
  "user_id": "uuid",
  "command": "rm -rf /tmp/cache",
  "exit_code": 0,
  "duration_ms": 123,
  "timestamp": "2026-01-26T23:45:00Z",
  "ip_source": "192.168.1.4"
}

Visible dans l'onglet Audit avec filtres par instance/commande.

1.5 Securite

• Commandes dangereuses: warning avant execution (rm -rf, dd, mkfs, etc.)
• Rate limiting par instance
• Timeout obligatoire (max 5 min)
• Pas de shell interactif persistant (stateless)
• Cles privees chiffrees avec cle derivee du user

Implementation technique

connectors-api/
  src/
    services/
      ssh.ts          # Service SSH (ssh2 library)
    routes/
      ssh.ts          # Routes /api/ssh/*
    types/
      ssh.ts          # Types SSH

Librairie: ssh2 (Node.js, mature, bien maintenue)

Phase 2: Testeur d'Endpoints

Concept

Sur la page d'une instance connectee, ajouter un onglet "Tester" avec un mini-formulaire pour executer les endpoints en direct.

UI/UX

/connectors/instance/{id}

Onglets: [Infos] [Endpoints] [Tester] [Logs]

=== Onglet Tester ===

[ Dropdown: GET /users           v ]
[ Dropdown: Method: GET          v ]

Parametres:
  [ user_id: ________ ]
  [ include_profile: [x] ]

Headers (optionnel):
  [ X-Custom: ________ ]

Body (POST/PUT):
  [ JSON editor ]

[Executer]

--- Response ---
Status: 200 OK (234ms)
{
  "id": "123",
  "name": "John"
}

Pour SSH: Mode Shell

=== Onglet Shell (SSH uniquement) ===

Historique:
> ls -la
drwxr-xr-x  5 user user 4096 Jan 26 23:00 .
-rw-r--r--  1 user user  220 Jan 26 22:00 .bashrc

> pwd
/home/user

> _
[Entree pour executer]

[Effacer historique] [Exporter logs]

Note: Ce n'est PAS un vrai terminal interactif (pas de vim, top, etc.) C'est un executeur de commandes one-shot avec historique affiche.

Implementation

connectors-front/
  src/
    components/
      EndpointTester.tsx    # Formulaire generique
      SshShell.tsx          # Interface shell-like
    routes/
      connectors/
        instance/
          [id]/
            test/index.tsx  # Page testeur

Schema Base de Donnees

Table ssh_instances (extension de instances)

-- Pas de nouvelle table, on utilise instances avec:
-- connector_type = 'ssh'
-- + metadata JSONB pour config SSH specifique

ALTER TABLE instances ADD COLUMN IF NOT EXISTS
  ssh_config JSONB DEFAULT NULL;

-- ssh_config example:
{
  "host": "192.168.1.10",
  "port": 22,
  "username": "gouroubleu",
  "auth_method": "auto_key",
  "private_key_encrypted": "...",  -- si auto_key ou key
  "fingerprint": "SHA256:..."      -- pour verification
}

Table ssh_audit_logs

CREATE TABLE ssh_audit_logs (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  instance_id UUID REFERENCES instances(id),
  user_id UUID REFERENCES users(id),
  command TEXT NOT NULL,
  cwd TEXT,
  exit_code INTEGER,
  stdout TEXT,
  stderr TEXT,
  duration_ms INTEGER,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX idx_ssh_audit_instance ON ssh_audit_logs(instance_id);
CREATE INDEX idx_ssh_audit_user ON ssh_audit_logs(user_id);
CREATE INDEX idx_ssh_audit_created ON ssh_audit_logs(created_at DESC);

Avantages

1. Centralisation: Toutes les connexions SSH gerees au meme endroit
2. Audit complet: Qui a execute quoi, quand, ou
3. Securite: Cles gerees automatiquement, pas de passwords qui trainent
4. API unifiee: Meme pattern que les autres connecteurs
5. Testeur universel: Valable pour SSH et tous les autres connecteurs

Risques / Considerations

Questions pour l'utilisateur

1. Priorite Phase 1 vs Phase 2?

   • SSH d'abord puis testeur?
   • Ou testeur d'abord (plus simple)?

2. Mode auto_key obligatoire?

   • Forcer la generation de cles apres premiere connexion?
   • Ou laisser le choix password/key?

3. Limites commandes?

   • Blacklist certaines commandes?
   • Ou tout autoriser avec warning?

4. Shell-like pour SSH:

   • Interface minimaliste (juste input + output)?
   • Ou plus avance (historique, completion, etc.)?

Estimation

Decision

[ ] Approuve - Commencer Phase 1 (SSH) [ ] Approuve - Commencer Phase 2 (Testeur) d'abord [ ] Modifie - Ajustements demandes [ ] Rejete - Autre direction