Un tunnel SSH permet de faire transiter un flux réseau par une machine distante reliée en SSH. En pratique, on s’en sert pour acceder a un service distant, exposer un service local à l’autre bout, ou faire passer certaines applications par un proxy socks ssh. Le point à retenir est simple : du point de vue du service contacté, l’adresse IP visible n’est souvent pas celle du client, mais celle de la machine qui porte le tunnel.
Sommaire
Les trois formes de tunnel SSH et leur syntaxe
Il existe trois formes principales de ssh tunnel, chacune avec une syntaxe précise.
- Redirection locale : on ouvre un port sur la machine cliente, puis SSH envoie le trafic vers une cible vue depuis le serveur distant.
ssh -L 8080:127.0.0.1:80 utilisateur@serveur
Cette commande n’affiche souvent rien si tout se passe bien. Avec l’option -N, elle garde simplement la session ouverte pour porter le tunnel.
- Redirection distante : on ouvre un port sur la machine distante, puis ce trafic revient vers un service accessible depuis la machine cliente.
ssh -R 8080:127.0.0.1:3000 utilisateur@serveur
Cette commande n’affiche pas forcément de message. Selon le serveur SSH, la redirection distante peut échouer si l’option AllowTcpForwarding est désactivée, ou si GatewayPorts limite l’écoute.
- Proxy SOCKS dynamique : SSH crée un proxy local, et l’application configurée dessus laisse SSH choisir la destination demandée.
ssh -D 1080 utilisateur@serveur
Là encore, il n’y a pas toujours de sortie visible. Le port 1080 devient un proxy SOCKS local tant que la session reste ouverte.
Ces trois formes relèvent de la redirection de port ssh, mais elles ne servent pas au même trafic, ni à la même visibilité d’adresse IP.
Ce que change le tunnel pour l’adresse IP vue par le service
C’est le point le plus utile pour comprendre un tunnel ssh. Quand vous passez par une redirection locale ou un proxy SOCKS dynamique, le service distant voit généralement l’adresse IP publique du serveur SSH, pas celle de votre poste. Le flux sort depuis la machine distante, comme s’il avait été initié depuis elle.
Exemple concret : si votre ordinateur a l’IP publique 198.51.100.24, que votre serveur SSH a l’IP 203.0.113.10 et que vous ouvrez un site via ssh -D 1080 utilisateur@serveur, le site verra en principe 203.0.113.10. Cela ressemble à différences entre un tunnel SSH et un VPN, mais la portée n’est pas la même.
À l’inverse, avec une redirection distante, le service qui se connecte au port publié sur le serveur ne voit pas forcément votre IP de client SSH. Il parle d’abord à la machine distante, qui relaie ensuite le flux. Le détail dépend du service final et du sens de la connexion.
Pour comprendre pourquoi cela fonctionne ainsi, il faut avoir en tête le fonctionnement de TCP/IP et la séparation entre machine cliente, serveur SSH et service final. Selon les cas, vous utilisez une machine tierce pour sortir vers Internet, ou pour rentrer vers un service local.
Comparer les trois options de redirection de port SSH
| Option | Sens du trafic | Cas d’usage | Ce que voit le service distant |
|---|---|---|---|
-L |
Client local vers service accessible depuis le serveur SSH | Accéder à une interface web liée à 127.0.0.1 sur un serveur distant | L’IP du serveur SSH ou de la machine qui initie la connexion finale |
-R |
Machine distante vers service accessible depuis le client | Publier temporairement un service local sur un serveur distant | L’IP de la machine distante qui relaie, pas forcément celle du client SSH |
-D |
Applications locales via proxy SOCKS vers destinations variées | Navigateur ou client applicatif passant par un proxy dynamique | L’IP publique du serveur SSH |
Ce tableau résume la logique générale. Dans tous les cas, le tunnel ne transforme pas SSH en routage complet du système. Si vous cherchez un mécanisme plus large, la comparaison avec Réseaux montre vite qu’on reste sur un transport ciblé de flux TCP, pas sur une bascule intégrale de tout le trafic.
Utiliser une redirection locale pour accéder à un service distant
La redirection locale est la plus fréquente pour acceder a un service distant qui n’écoute que sur 127.0.0.1 côté serveur. C’est le cas d’un tableau d’administration lié à localhost:8080, d’une base de données ou d’une interface HTTP non exposée publiquement.
Commande type :
ssh -L 8080:127.0.0.1:80 utilisateur@serveur
Cette commande ouvre le port local 8080. Si vous visitez ensuite http://127.0.0.1:8080 dans votre navigateur, SSH transmet la requête vers 127.0.0.1:80 vue depuis le serveur distant. Le navigateur n’affiche rien dans le terminal SSH, mais la page demandée apparaît si le service répond.
Variante avec ssh -l :
ssh -l utilisateur -L 8080:127.0.0.1:80 serveur
Le rôle de ssh -l est simplement de préciser le nom d’utilisateur de connexion au lieu d’écrire utilisateur@serveur.
Cas d’usage réel : consulter une interface d’administration HTTP d’un serveur Linux qui n’écoute pas sur l’extérieur. Avant d’ouvrir le tunnel, vous pouvez vérifier qu’un port distant est ouvert si vous travaillez sur un service HTTPS ou sur un port spécifique.
Piège classique : confondre l’hôte final. Dans -L 8080:127.0.0.1:80, l’adresse 127.0.0.1 est résolue depuis le serveur SSH, pas depuis votre machine locale. C’est souvent la source des erreurs de diagnostic.
Utiliser une redirection distante pour publier un service local
La redirection distante sert à exposer, via un serveur SSH, un service qui tourne chez vous ou sur la machine cliente. C’est le sens inverse du cas précédent.
Commande type :
ssh -R 8080:127.0.0.1:3000 utilisateur@serveur
Cette commande demande au serveur SSH d’écouter sur son port 8080 et de renvoyer le trafic reçu vers 127.0.0.1:3000 vu depuis votre machine cliente. Si une application web locale écoute sur le port 3000, elle devient joignable via le serveur distant.
En sortie, certains serveurs OpenSSH affichent un message de confirmation en mode verbeux :
ssh -v -R 8080:127.0.0.1:3000 utilisateur@serveur
Vous verrez alors des lignes du type Remote connections from LOCALHOST:8080 forwarded to local address 127.0.0.1:3000.
Cas d’usage réel : montrer temporairement une application de développement locale à une machine distante dont vous contrôlez l’accès. Cette méthode dépend du serveur SSH distant. Si AllowTcpForwarding vaut no, la redirection de port SSH est refusée. Si l’écoute doit être accessible hors du serveur lui-même, GatewayPorts entre aussi en jeu, et il est souvent désactivé par défaut.
Piège classique : croire que le port publié est visible partout sur Internet. Très souvent, il n’écoute que sur 127.0.0.1 côté serveur distant, donc seulement depuis cette machine elle-même, sauf configuration explicite.
Créer un proxy SOCKS SSH pour certaines applications
Le mode dynamique transforme SSH en proxy socks ssh. C’est utile quand l’application sait parler à un proxy SOCKS 5, comme la plupart des navigateurs modernes, certains gestionnaires de paquets ou des clients HTTP avancés.
Commande type :
ssh -D 1080 utilisateur@serveur
Cette commande ouvre un proxy SOCKS local sur le port 1080. Ensuite, dans l’application, vous indiquez 127.0.0.1 comme serveur SOCKS, port 1080, généralement en SOCKS5. Si l’application est bien configurée, le trafic sortira via la machine distante, qui sera donc visible pour le service joint.
Cas d’usage réel : faire passer le trafic d’un navigateur précis par un serveur SSH, sans modifier la route par défaut du système. C’est l’une des raisons pour lesquelles on compare souvent cela à masquer son adresse IP, même si la mécanique reste applicative.
Piège classique : penser que tout le poste passe automatiquement dans le tunnel. Ce n’est pas le cas. Seules les applications configurées pour utiliser le proxy SOCKS l’emploient réellement. Si le navigateur n’utilise pas ce proxy, il continue de sortir directement avec l’adresse IP du poste.
Préparer la machine distante et garder un accès stable
Avant d’ouvrir un tunnel, vérifiez trois points : l’accès SSH, le service cible, et le nom ou l’adresse du serveur. La commande la plus simple reste :
ssh utilisateur@serveur
Si la connexion fonctionne, SSH affiche généralement une invite de shell distante, par exemple utilisateur@serveur:~$.
Si l’adresse IP du serveur change régulièrement, il devient pratique de joindre une machine distante avec un DNS dynamique. Cela évite de rechercher la nouvelle IP à chaque reconnexion.
Pour des sessions dédiées au tunnel, on ajoute souvent -N pour ne pas ouvrir de shell, et -f pour envoyer SSH en arrière-plan :
ssh -f -N -L 8080:127.0.0.1:80 utilisateur@serveur
Si tout va bien, la commande rend la main au terminal sans sortie notable, tandis que le tunnel reste actif en arrière-plan. Si un mot de passe est demandé et qu’aucun agent SSH n’est disponible, le comportement dépend de votre environnement.
Limites, différences avec un VPN et erreurs fréquentes
Un tunnel SSH n’est pas un VPN. Il ne couvre pas l’ensemble du trafic système, sauf montage plus complexe hors du cadre de ce guide. Un VPN modifie souvent la route de sortie à l’échelle du système ou d’une interface réseau virtuelle, alors qu’un tunnel SSH transporte seulement ce qu’on lui demande.
La conséquence directe est simple : le service distant voit l’IP de la machine porteuse du tunnel seulement pour les flux qui passent effectivement dedans. Les autres connexions gardent votre sortie réseau habituelle. Pour distinguer les deux approches, on peut aussi rapprocher cela des notions d’IP publique et privée, ou d’interface de sortie, sans supposer un changement global d’identité réseau.
Autres limites à retenir :
- Le proxy SOCKS demande une configuration côté application.
- La redirection distante dépend de la configuration du serveur SSH, notamment
AllowTcpForwardinget parfoisGatewayPorts. - SSH transporte ici des flux TCP. La prise en charge d’autres protocoles n’est pas générale dans ce mode.
- Un tunnel actif ne prouve pas que le service final répond correctement. Il faut aussi tester l’application cible.
Questions fréquentes
Qu’est-ce qu’un tunnel SSH ?
Un tunnel SSH est un canal chiffré qui fait passer une connexion réseau par une session SSH. Il sert à rediriger un port local, un port distant ou des connexions applicatives via un proxy SOCKS. On l’utilise pour joindre un service sans l’exposer directement sur Internet. Le service atteint voit souvent l’adresse IP de la machine distante qui porte le tunnel.
Quelle différence entre un tunnel SSH et un VPN ?
Un tunnel SSH agit généralement sur un flux précis ou sur les applications configurées pour l’utiliser. Un VPN redirige en général tout ou partie du trafic système via une interface réseau dédiée. Les deux peuvent faire apparaître l’IP du serveur intermédiaire, mais leur portée technique n’est pas la même. Le tunnel SSH reste plus ciblé et plus limité.
Comment créer un tunnel SSH ?
La méthode dépend du besoin. Pour une redirection locale, utilisez ssh -L 8080:127.0.0.1:80 utilisateur@serveur. Pour une redirection distante, utilisez ssh -R 8080:127.0.0.1:3000 utilisateur@serveur. Pour un proxy SOCKS dynamique, utilisez ssh -D 1080 utilisateur@serveur, puis configurez l’application pour employer ce proxy.
Le service distant voit-il ma vraie adresse IP ?
Pas toujours. Si la connexion passe réellement dans le tunnel, le service voit en général l’adresse IP publique de la machine distante qui relaie le flux. Si l’application n’utilise pas le tunnel, elle continue de sortir avec votre adresse habituelle. Avec SSH, tout dépend donc du type de redirection choisi et de la manière dont l’application envoie son trafic.
