SSH: tunneling

SSH ne transfère pas que des fichiers: il fait passer n’importe quel protocole TCP dans le canal chiffré. Une connexion VNC, une base MySQL, un serveur web interne, un SMB share: tout ce qui est TCP peut être tunnelé à travers SSH, sans VPN, sans configuration firewall, avec une seule commande.

Le tunnel local (local forward)

ssh -L 3306:localhost:3306 user@serveur

Cette commande ouvre le port 3306 sur votre machine locale et tout ce qui y arrive part vers le port 3306 de serveur (vu depuis serveur). Une session SSH est ouverte, le tunnel fonctionne tant que la session dure.

Pour accéder à MySQL sur serveur:

mysql -h 127.0.0.1 -P 3306 -u root -p

Le -h 127.0.0.1 est crucial: le tunnel est local, MySQL voit une connexion depuis localhost sur serveur, ce qui contourne les restrictions de bind-address.

Le tunnel distant (remote forward)

ssh -R 8080:localhost:80 user@serveur

Cette commande ouvre le port 8080 sur serveur et tout ce qui y arrive part vers le port 80 de votre machine locale. Le sens inverse du local forward: vous exposez un service local sur un serveur distant.

Cas d’usage: votre machine est derrière un NAT/firewall et vous voulez exposer un serveur web local. Le tunnel distant l’expose via serveur:8080.

Le tunnel dynamique (SOCKS proxy)

ssh -D 1080 user@serveur

Cette commande ouvre un proxy SOCKS5 sur le port 1080 de votre machine. Configurez Firefox pour utiliser 127.0.0.1:1080 comme proxy SOCKS5 et tout le trafic web passe par serveur: le DNS, le HTTP, le HTTPS. C’est le VPN du pauvre: pas de config réseau, pas de client VPN, juste un SSH et un proxy navigateur.

Cas d’usage: accéder à un réseau interne depuis l’extérieur. Le serveur SSH est dans le réseau, le proxy SOCKS vous y projette.

Le tunneling multi-hop

Pour atteindre une cible derrière un rebond, on chaîne les connexions avec ProxyCommand et nc sur l’intermédiaire:

ssh -o ProxyCommand="ssh user@intermediaire nc final 22" user@final

L’intermédiaire ouvre une connexion TCP vers le port 22 du final avec nc et le SSH local négocie son chiffrement de bout en bout à travers ce tube: le rebond voit passer du trafic chiffré qu’il ne peut pas lire. C’est le pattern des bastions et son mérite est qu’on ne stocke aucune clé sur le rebond, la clé et la session restent sur la machine d’origine.

[edit: 2026] Les trois forwards (local, remote, dynamic) n’ont pas bougé d’un pouce. Le multi-hop en ProxyCommand a été simplifié depuis par ProxyJump, l’option -J apparue avec OpenSSH 7.3, dont je parle dans un billet dédié, SSH: ProxyJump et le multi-hop moderne . WireGuard a pris entre-temps le rôle de VPN sérieux, mais pour une connexion ponctuelle à un service interne, le tunneling SSH reste plus simple: une commande, pas de config réseau.

[edit: 2026] L’implémentation Ansible de tout ceci: les rôles ssh et wireguard .