Aller au contenu principal

Reverse SSH Tunnel

Quand ta base de donnees vit sur ta machine locale, derriere un NAT residentiel, dans Docker Desktop ou derriere un firewall d'entreprise, elle n'a pas d'IP publique joignable. KytheraDB ne peut pas s'y connecter directement — par contre ton poste peut sortir vers Internet. Le reverse SSH tunnel exploite cette asymetrie : un tunnel sortant que tu lances depuis ton terminal, et KytheraDB le ré-utilise pour atteindre ta base.

Aucun port à ouvrir cote toi, aucune installation cote KytheraDB, aucune modification de ta config reseau. Juste un ssh lance dans un terminal.

Quand utiliser cette feature​

Tu utilises le reverse SSH tunnel si au moins une de ces conditions s'applique :

  • ✅ Ta base est dans Docker Desktop ou un cluster local (kind, minikube, k3d)
  • ✅ Ta base est sur ton poste de developpement (Postgres installe en local, MySQL pour un side-project)
  • ✅ Tu es chez toi derriere une box residentielle (NAT/CGNAT, pas d'IP fixe)
  • ✅ Ta base est derriere un firewall d'entreprise qui n'autorise pas l'entrant mais autorise le SSH sortant
  • ✅ Tu ne veux pas exposer publiquement ta base meme si tu pourrais

A l'inverse, n'utilise PAS le tunnel si :

  • ❌ Ta base est deja publique sur Internet (RDS, Supabase, Neon, etc.) → connexion directe, plus rapide et plus simple
  • ❌ Tu as deja un bastion SSH d'entreprise → branche-le dans le champ ssh_config de la connexion (BYO bastion)
  • ❌ Tu as besoin d'une connexion persistante 24/7 non supervisee → le tunnel expire toutes les 2h par defaut (limite de securite)

Comment ca marche, etape par etape​

1. Genere une session tunnel cote KytheraDB​

Dans le formulaire de creation de connexion, active le toggle "Utiliser un tunnel SSH".

Renseigne le port sur lequel ta base tourne en local :

Type de basePort par defaut
PostgreSQL5432
MySQL / MariaDB3306
SQL Server1433
Postgres dans Docker remappedepend de ports: dans ton compose, ex 5444

Clique "Creer la session". KytheraDB genere :

  • Une paire de cles ed25519 jetable (clef privee renvoyee UNE seule fois, jamais persistee cote serveur)
  • Une session UUID valide 2h
  • Une commande SSH copy/paste

2. Telecharge la cle privee​

Bouton "Telecharger" → un fichier auralith-tunnel-xxxxxxxx.pem arrive dans tes downloads. Garde-le, tu en as besoin pour la commande SSH ; il sera detruit a l'expiration de la session.

3. Lance la commande SSH dans ton terminal​

Copie-colle la commande pre-formatee. Elle ressemble a :

ssh -N -i auralith-tunnel-abcd1234.pem \
    -R 25042:localhost:5432 \
    abcd1234-...@tunnel.kytheradb.com -p 2222

Decomposition :

  • -N : pas de commande distante, juste le tunnel
  • -i <fichier.pem> : clef privee telechargee a l'etape 2
  • -R 25042:localhost:5432 : reverse forward — le port 25042 cote KytheraDB route vers localhost:5432 cote toi (ta base locale)
  • <session-uuid>@tunnel.kytheradb.com -p 2222 : le serveur SSH KytheraDB

Laisse ce terminal ouvert. Tant qu'il tourne, le tunnel est actif. Ferme-le et la connexion est interrompue. C'est volontaire — tu controles physiquement la fenetre d'exposition.

4. Finalise la connexion dans KytheraDB​

Le formulaire est deja pre-rempli avec :

  • Host : host.docker.internal
  • Port : 25042 (le port alloue par KytheraDB cote serveur)

Tu n'as qu'a remplir :

  • Database (ex: zendica)
  • User (ex: zendica)
  • Password (ex: zendica_dev)
  • SSL Mode : disable ou prefer selon ta config Postgres locale

Clique "Tester la connexion" → KytheraDB se connecte a host.docker.internal:25042 qui forwarde via le tunnel vers ton localhost:5432. OK = tout marche.

Securite : ce qu'on garantit​

Le reverse SSH tunnel a ete concu pour qu'aucun acteur malicieux ne puisse en abuser, meme si une cle fuite.

Authentification​

  • Cle publique uniquement — pas de mot de passe. Si la cle privee fuite, tu peux la revoquer en 1 clic.
  • Cle liee a une session UUID specifique — meme une cle valide ne marche pas pour une autre session.
  • Session a duree limitee — 2h par defaut (TUNNEL_SESSION_TTL_HOURS).

Restrictions cote serveur SSH​

Le serveur SSH embarque refuse TOUT sauf le reverse forward strict :

Demande SSHReponse
Mot de passe❌ refuse
Shell interactif❌ refuse
Execution de commande (ssh user@host commande)❌ refuse
-L (forward sortant depuis serveur) — abuser comme proxy SOCKS❌ refuse
-R (reverse) sur 0.0.0.0 — exposer le port sur Internet❌ refuse
-R sur 127.0.0.1 dans la plage 25000-25999✅ autorise

Quotas anti-abus​

  • Rate limit 10 sessions creees / heure / IP (slowapi)
  • Max 5 sessions actives simultanees / user
  • Audit log de chaque tentative SSH (succes ET echecs, avec IP)

Chiffrement de bout-en-bout​

HopChiffrement
Ton terminal → serveur KytheraDBSSH ed25519 + ChaCha20-Poly1305 (PFS via curve25519)
Backend KytheraDB → browserTLS 1.3 (Let's Encrypt)
Stockage des connexions DBFernet AES-128 + HMAC + IV per record

Le seul moment ou la donnee n'est pas chiffree = sur ton loopback (127.0.0.1) cote toi et le loopback cote container backend. Ces deux segments ne sortent jamais d'une machine.

Revocation immediate​

Bouton "Revoquer" dans l'interface → la session est invalidee instantanement. La prochaine tentative d'authentification SSH echoue, et le tunnel actif est coupe.

La checklist operationnelle complete cote infra (durcissement du serveur SSH, fail2ban, rotation des sessions) est maintenue en interne par l'equipe ops.

Troubleshooting​

ssh: connect to host tunnel.kytheradb.com port 2222: Connection timed out​

Le port 2222 n'est pas accessible depuis ton reseau. Causes possibles :

  1. Firewall residentiel / FAI qui bloque le sortant sur le port 2222 (rare en France, peut arriver en entreprise)
  2. Cloudflare ne proxifie pas le 2222 si tu utilises kytheradb.com au lieu de tunnel.kytheradb.com — utilise bien le sous-domaine tunnel. qui est en DNS-only

Test rapide : Test-NetConnection tunnel.kytheradb.com -Port 2222 (PowerShell) ou nc -vz tunnel.kytheradb.com 2222 (mac/Linux). Si False → c'est ton reseau qui bloque le port sortant.

Permission denied (publickey)​

Cause typique : tu utilises la mauvaise cle, ou la session a expire / ete revoquee. Recree une session et refais l'operation. Si ca persiste, verifie que le fichier .pem n'a pas ete modifie au telechargement (les editeurs peuvent ajouter des sauts de ligne sur Windows).

Connexion etablie mais KytheraDB ne peut pas atteindre ma base​

Le tunnel marche cote SSH mais KytheraDB n'arrive pas a se connecter a host.docker.internal:25042. Causes :

  1. Ta base Postgres locale n'ecoute pas sur 127.0.0.1 — verifie ton postgresql.conf (listen_addresses = 'localhost' au minimum)
  2. Le pg_hba.conf rejette la connexion depuis loopback — ajoute une ligne host all all 127.0.0.1/32 md5 (ou scram-sha-256)
  3. Le bon port n'est pas mappe — si ta base Docker tourne sur le port 5444 et que tu as mis 5432 dans la commande SSH, ca rate. Re-cree la session avec le bon port.

Aucun port tunnel disponible (503)​

Toute la plage 25000-25999 est saturee. C'est extremement rare en pratique (1000 ports). Si tu rencontres ca : tes anciennes sessions traînent — utilise "Revoquer" sur les sessions inactives. Sinon contacte le support.

Limites connues​

  • TTL court (2h par defaut) : c'est volontaire pour limiter la fenetre d'exposition. Si tu veux une connexion persistante, lance un service systemd ou un PowerShell job en arriere-plan qui re-cree la session toutes les 2h.
  • Une session par fenetre terminal : tu peux avoir plusieurs tunnels en parallele mais chacun bloque un terminal.
  • Pas de Windows-without-OpenSSH : Windows 10+ a OpenSSH natif. Sur Windows plus ancien, installe Git Bash ou WSL.
  • Pas de bind LAN : si tu veux exposer ta base a d'autres devs sur ton LAN via le meme tunnel, c'est pas possible — le -R est restreint a 127.0.0.1 cote serveur.

Pour les cas avances (bastion d'entreprise, tunnel persistant, multi-user) → contacte le support enterprise.