Générateur de commandes de tunnel SSH
Choisis une direction, glisse tes ports et tes hosts, et copie la commande de tunnel ssh plus un bloc ssh config assorti.
Ce générateur de tunnels SSH tranche la question que personne ne retient : tu veux -L, -R ou -D ? Choisis la direction, glisse tes ports et tes hosts, et tu récupères la commande ssh en une ligne plus un bloc ~/.ssh/config assorti à copier. Le local forwarding (-L) ramène un service distant ou interne sur un port de ta machine. Le remote forwarding (-R) pousse un de tes services locaux vers le côté serveur. Le dynamic forwarding (-D) monte un proxy SOCKS5 qui route n'importe quel trafic par la machine. Il gère aussi le jump host, l'identity file, les keepalives et les flags d'arrière-plan, et il explique chaque morceau pour que le piège du local-versus-remote arrête de te mordre. Tout tourne dans ton navigateur, donc les hostnames et les chemins de clés que tu tapes ne quittent jamais la page.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Générateur de commandes de tunnel SSH
Personne ne se souvient s'il lui faut -L, -R ou -D. Moi, je l'ai cherché une bonne centaine de fois. Du coup : choisis la direction, glisse tes ports et tes hosts, et tu récupères la commande ssh en une ligne plus un bloc ~/.ssh/config assorti à copier. Chaque morceau est expliqué, parce que cette histoire de local-versus-remote piège tout le monde, et franchement c'est normal. Tout tourne dans ton navigateur.
Ce que fait ce générateur de tunnels SSH
Ce générateur de tunnels SSH construit la commande de port-forwarding exacte qu'il te faut, puis te file un bloc de config assorti pour que tu arrêtes de le retaper. SSH, ce n'est pas qu'un shell. Il sait aussi pousser des ports réseau dans son tuyau chiffré, ce qui veut dire que tu peux atteindre des trucs privés ou coincés derrière un firewall. Il y a trois modes de forwarding : -L, -R et -D. Les gens les confondent sans arrêt. La syntaxe est presque identique, mais la direction est inversée, et c'est exactement là que se loge la confusion. Ce générateur te demande juste ce que tu veux atteindre et depuis où. Ensuite il te donne la bonne commande, plus une entrée ~/.ssh/config pour que tu arrêtes de retaper le bidule.
Local, remote et dynamic forwarding
| Mode | Ce qu'il fait | Exemple |
|---|---|---|
-L Local | Ramène un service distant sur un port local. Tu tapes sur localhost, tu atterris côté serveur. | ssh -L 8080:localhost:80 user@server |
-R Remote | Pousse un service local vers un port distant, pour que le serveur (ou qui que ce soit dessus) puisse revenir taper sur ta machine. | ssh -R 9000:localhost:3000 user@server |
-D Dynamic | Monte un proxy SOCKS local qui fait passer n'importe quel trafic par le serveur SSH. | ssh -D 1080 user@server |
Voilà le moyen mnémotechnique qui a fini par me rester. -L ramène un truc distant vers toi, c'est toi qui écoutes. -R envoie un truc local vers l'extérieur, c'est le remote qui écoute à la place. Et -D transforme tout simplement le serveur SSH en proxy vers lequel tu peux diriger ton trafic. Le flag -N dit à SSH de zapper le shell, parce que tu veux juste le tunnel, pas une invite de commande. -f le balance en arrière-plan.
Lire la syntaxe -L
Prends 8080:localhost:80. Ça veut dire : écoute sur le port local 8080, puis forward vers localhost:80 tel que le serveur SSH le voit. Ce dernier bout, c'est tout le truc, vraiment. Le localhost là-dedans, c'est le localhost du serveur, pas le tien. C'est la partie qui mord les gens, moi y compris, les douze premières fois. Disons que tu as une base de données que seul le serveur peut toucher. Tu écrirais -L 5432:db.internal:5432, où le serveur résout db.internal, et ensuite tu pointes ton client sur localhost:5432.
Sauvegarder ses tunnels dans le ssh config
Retaper une longue commande de tunnel, c'est comme ça qu'on se retrouve avec une faute de frappe à 2h du mat. Du coup le générateur te file aussi un bloc ~/.ssh/config, en utilisant celui qui convient parmi LocalForward, RemoteForward ou DynamicForward. Tu le sauvegardes une fois. Après ça, le tunnel se résume à ssh mytunnel. Le config range aussi l'utilisateur, le port, l'identity file, le keepalive, tout ça au même endroit, pour que tes commandes restent courtes et que toute l'équipe lance exactement la même chose.
Confidentialité et fonctionnement de l'outil
C'est du JavaScript qui construit la commande et le bloc de config directement dans ton navigateur. Les hostnames et les chemins de clés que tu tapes ne quittent jamais la page, et rien n'est loggé nulle part. Ce qui compte un peu plus ici que d'habitude, vu qu'une config de tunnel décrit en général ton réseau interne.
Sources et pour aller plus loin
- man7.org : page de man ssh(1) (port forwarding)
- RFC 4254 : SSH Connection Protocol (channels et forwarding)
- OpenSSH : manuels officiels
Questions fréquentes
Quelle est la différence entre ssh -L et -R ?
-L (local) écoute sur ta machine et forward vers quelque chose que le serveur peut atteindre, donc tu accèdes à un service distant via localhost. -R (remote) inverse tout : le serveur écoute, puis forward vers quelque chose que ta machine peut atteindre, donc le côté serveur peut venir tâter un de tes services locaux. Le bout que j'ai vraiment retenu, moi : -L ramène vers toi, -R pousse vers l'extérieur.
Comment créer un proxy SOCKS avec SSH ?
Le dynamic forwarding s'en charge : ssh -D 1080 -N user@server. Ça te donne un proxy SOCKS5 sur le port local 1080, et tout ce que tu envoies au travers ressort en tunnel via le serveur. Pointe ton navigateur ou ton appli sur socks5://localhost:1080. Pratique sur le wifi douteux d'un café.
Pourquoi mon tunnel -L se connecte au mauvais host ?
Dans -L localport:host:hostport, ce host est résolu par le serveur SSH, pas par toi. Donc si tu as tapé localhost, tu viens de demander le serveur lui-même. Tu veux une autre machine interne ? Mets le nom ou l'IP que le serveur peut voir, genre -L 5432:db.internal:5432. J'ai perdu deux bonnes heures sur exactement cette erreur.
À quoi servent -N et -f ?
-N dit de ne pas lancer de commande distante, ce qui est ce que tu veux pour un tunnel, donc aucune invite de shell n'apparaît. -f bascule SSH en arrière-plan une fois l'authentification faite. Colle-les ensemble et -fN devient la vieille recette fiable pour un tunnel en arrière-plan.
Comment empêcher un tunnel SSH de tomber ?
Ajoute des keepalives : -o ServerAliveInterval=60 fait envoyer une sonde à SSH toutes les 60 secondes, pour qu'il remarque vraiment quand le lien meurt. Ça stoppe les coupures d'inactivité. En revanche, il ne se reconnectera pas tout seul. Pour ça, enrobe le tunnel dans autossh, ou lance-le comme service systemd avec Restart=always.