Tunnel SSH : Redirection de Ports avec -L, -R, -D

Comment atteindre une base de données qui n’écoute que sur localhost ?

Une instance Postgres sur un serveur distant est liée à 127.0.0.1 volontairement. Rien sur le réseau ne peut l’atteindre, seuls les processus qui tournent sur cette même machine le peuvent. Votre ordinateur portable n’est pas cette machine, donc psql -h remote-server -p 5432 échoue avant même d’arriver à l’authentification. Ouvrir le port au monde entier annulerait la raison même pour laquelle il a été lié au loopback.

Ce que vous voulez, c’est emprunter, pour quelques minutes, la vue que la machine distante a de 127.0.0.1, depuis votre propre terminal. Dès que vous vous connectez, SSH a déjà ouvert une connexion chiffrée et authentifiée entre les deux machines. Le port forwarding réutilise cette connexion pour transporter un trafic autre que celui de votre shell.

Comment fonctionne le port forwarding SSH sous le capot ?

Une session SSH classique ressemble à un simple tuyau : les touches entrent, la sortie du terminal revient. En dessous, le protocole multiplexe plusieurs canaux indépendants sur cette unique connexion chiffrée. Le shell est un canal. Une connexion TCP redirigée en est un autre.

Demandez à ssh de rediriger un port : il ouvre un nouveau canal pour chaque connexion établie vers ce port, transporte les octets bruts à travers la session existante et les remet de l’autre côté. Pas de nouveau certificat, pas de second login. Le tunnel hérite de l’accès que possède déjà le login SSH.

Gardez cela en tête avant de regarder les options. -L, -R et -D ne sont pas trois mécanismes différents. Ils orientent le même mécanisme de channel-forwarding dans des directions différentes.

Comment utiliser la redirection de port locale SSH (-L) ?

1

ssh -L 5432:localhost:5432 [email protected]

Lisez l’argument de -L comme local_port:destination_host:destination_port. Cela ouvre le port 5432 sur votre ordinateur portable. Tout ce qui s’y connecte est redirigé à travers le tunnel vers localhost:5432 tel que vu depuis db-host, c’est-à-dire l’instance Postgres liée à son propre loopback. Dans un second terminal :

1

psql -h localhost -p 5432 -U app appdb

psql pense parler à une base de données locale. Il parle en réalité à l’interface de loopback de db-host à travers SSH.

L’hôte de destination au milieu n’a pas besoin d’être le serveur SSH lui-même :

1

ssh -L 5432:internal-db.corp:5432 jumpbox.example.com

Cela redirige via jumpbox vers une troisième machine que jumpbox peut atteindre et que vous ne pouvez pas. C’est la forme que la plupart des gens ont en tête en parlant de « tunnel SSH » : une machine qui a l’accès que vous n’avez pas, redirigeant vers un réseau que vous ne pourriez pas toucher autrement. Si Postgres tourne déjà en local, le port 5432 de votre portable est pris ; choisissez un autre port local comme 15432 et passez -p 15432 à psql.

Comment exposer un port local avec la redirection distante SSH (-R) ?

-R fait la même chose à l’envers. La syntaxe est remote_port:destination_host:destination_port, mais le listener s’ouvre côté distant.

1

ssh -R 8080:localhost:3000 [email protected]

public-host écoute maintenant sur le port 8080, et toute connexion vers ce port revient à travers le tunnel jusqu’à localhost:3000 sur votre machine : votre serveur de développement local. Vous obtenez une adresse joignable pour un fournisseur de webhooks ou un collègue sans ouvrir de port sur votre propre pare-feu, en empruntant une machine qui en a déjà un.

Un comportement par défaut surprend souvent. sshd lie les ports redirigés à distance à l’interface de loopback de l’hôte distant, donc curl public-host:8080 depuis une troisième machine échoue même si la redirection tourne. Seuls les processus sur public-host lui-même peuvent l’atteindre. Changer cela nécessite GatewayPorts yes dans le sshd_config de ce serveur, un réglage que seul l’administrateur du serveur peut changer. Aucune option sur votre commande ssh ne le contourne.

Comment transformer un tunnel SSH en proxy SOCKS (-D) ?

-L et -R redirigent chacun vers une destination fixe, décidée au lancement de la commande. -D ne choisit aucune destination :

1

ssh -D 1080 [email protected]

Cela ouvre un proxy SOCKS sur localhost:1080. Toute application pointée vers ce port choisit la destination pour chaque connexion, et ssh la relaie depuis la position de remote-host sur le réseau :

1

curl --socks5-hostname localhost:1080 https://internal-service.corp/status

La partie -hostname compte. Avec le simple --socks5, curl résout internal-service.corp sur votre portable, où ce nom n’existe pas, et échoue avant même que le proxy ne soit utilisé. --socks5-hostname envoie le nom à travers le tunnel pour que ce soit remote-host qui le résolve.

Les navigateurs fonctionnent de la même façon une fois le proxy configuré dans leurs paramètres réseau (et « Proxy DNS lors de l’utilisation de SOCKS v5 » activé dans Firefox). Chaque site voit alors l’IP de remote-host et passe par ses règles de pare-feu. C’est ainsi que vous atteignez tout un réseau interne à travers un seul jump box, ou que vous vérifiez ce qu’un site sert à une autre région, sans écrire une redirection distincte pour chaque destination.

Quel type de redirection SSH choisir : -L, -R ou -D ?

Comment garder un tunnel SSH ouvert en arrière-plan ?

Deux problèmes apparaissent vite : retaper la commande complète à chaque fois, et le tunnel qui meurt à la fermeture du terminal. ~/.ssh/config règle le premier :

1
2
3
4
5

Host db-tunnel
    HostName db-host.example.com
    User deploy
    LocalForward 5432 localhost:5432
    LocalForward 6379 localhost:6379

ssh db-tunnel ouvre désormais les deux redirections en une fois. LocalForward, RemoteForward et DynamicForward correspondent à -L, -R et -D, une ligne par redirection, autant que nécessaire dans un bloc Host.

Pour une redirection qui doit rester active sans surveillance, ajoutez -N (n’exécuter aucune commande distante, garder seulement le tunnel) et -f (passer en arrière-plan après authentification), plus un keepalive pour qu’une connexion coupée silencieusement soit détectée au lieu de rester bloquée :

1

ssh -N -f -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" db-tunnel

Cela ne se reconnecte pas pour autant quand le réseau tombe. ssh se termine et la redirection disparaît. autossh enveloppe la même commande et la relance quand la connexion meurt :

1

autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -N -f db-tunnel

-M 0 désactive le port de monitoring propre à autossh et laisse le keepalive ServerAlive* détecter une connexion morte. Sur OpenSSH moderne, c’est la configuration à utiliser.

Quand ne pas utiliser les tunnels SSH ?

Un port redirigé hérite de l’accès du login SSH qui l’a ouvert. Pratique quand c’est vous qui détenez la clé, et une exposition réelle si la clé ou la session sont compromises, car le tunnel offre tout ce que ce login peut atteindre. AllowTcpForwarding dans sshd_config est l’interrupteur côté serveur (yes par défaut). Le passer à no ferme cette voie, mais quiconque a un accès shell sur la machine peut toujours lancer son propre forwarder, donc cela n’aide que si vous restreignez aussi l’accès shell.

Les tunnels cessent aussi de passer à l’échelle au-delà d’une poignée de personnes ou de services. Chacun est un processus lié à un terminal ou à une instance autossh. Il n’y a pas d’endroit central pour voir qui a un tunnel ouvert, révoquer l’accès sans toucher à chaque configuration client, ou appliquer une politique unique à tous les utilisateurs. À ce stade, un VPN, ou un proxy qui authentifie chaque utilisateur devant le service, devrait remplacer le tas de tunnels personnels.

Ce n’est pas non plus le même outil qu’un reverse proxy ou Cloudflare Tunnel, même si les trois rendent joignable quelque chose qui ne l’était pas. Un reverse proxy se place en permanence devant un service et fait face à l’internet public. Cloudflare Tunnel est plus proche de -R : une connexion sortante depuis votre côté qui devient joignable depuis l’extérieur, mais à travers l’edge de Cloudflare, avec un hostname stable et aucun port serveur à gérer. Et tandis qu’un reverse proxy ou Cloudflare Tunnel s’appuient sur des certificats, comme expliqué dans comment fonctionne le handshake TLS, un tunnel SSH n’en a besoin d’aucun. Le chiffrement, c’est la session SSH elle-même, authentifiée par votre clé plutôt que par un certificat auquel un navigateur ferait confiance.

Que configurer en premier ?

Prenez le tunnel que vous retapez le plus souvent et transformez-le dès aujourd’hui en bloc Host dans ~/.ssh/config. Atteindre quelque chose que seul un hôte distant voit, c’est -L. Exposer un service local à travers une machine avec une adresse publique, c’est -R. Router le trafic d’une application à travers un réseau distant sans choisir les destinations à l’avance, c’est -D. Une fois dans le config, ssh -N -f db-tunnel suffit, et vous arrêtez de vous tromper de numéro de port à 23 heures.

Articles associés

• Qu’est-ce qu’un Reverse Proxy et Comment Il Fonctionne
• Exposer un Serveur Local avec Cloudflare Tunnel
• Qu’est-ce que TLS et Comment Fonctionne le Chiffrement HTTPS