Tunnel SSH

La base technique est définie dans la RFC 4254, The Secure Shell (SSH) Connection Protocol, publiée le 6 janvier 2006. Cette RFC définit comment SSH multiplexe une connexion de transport authentifiée vers plusieurs canaux logiques. L'un d'eux est le forwarding TCP/IP — le port forwarding. Une seule connexion SSH peut donc transmettre en toute sécurité plusieurs services réseau simultanément.

Les termes port forwarding et tunneling sont utilisés comme synonymes dans la documentation technique. La documentation d'Apache MINA SSHD indique explicitement que le port forwarding TCP/IP équivaut au tunneling : le proxy d'une connexion TCP/IP via un canal SSH. La couche de transport elle-même est décrite dans la RFC 4253, The Secure Shell (SSH) Transport Layer Protocol, également publiée le 6 janvier 2006. La RFC 4253 traite de l'échange de clés et de l'authentification. Ce n'est qu'ensuite que la couche de connexion, dans laquelle le port forwarding est défini, devient disponible.

Étapes : le port forwarding local

Le port forwarding local est la forme la plus utilisée. Vous reliez un port local sur votre propre machine à un port sur un serveur externe, via une connexion SSH. Red Hat documente la commande comme suit :

ssh -L local-port:remote-hostname:remote-port user@hostname

Étape 1 : Déterminez les paramètres du tunnel

Choisissez un port local libre sur votre machine. Choisissez le remote-hostname et le remote-port du service que vous souhaitez atteindre, vu depuis le serveur SSH. Pour un serveur web sur le serveur SSH lui-même, utilisez `localhost` comme remote-hostname et `80` comme remote-port.

Étape 2 : Ouvrez le tunnel

ssh -L 8080:localhost:80 user@192.168.1.10

Le client SSH écoute désormais sur le port local 8080. Chaque connexion vers ce port est chiffrée et envoyée au serveur SSH. Depuis le serveur, le trafic est transmis vers `localhost:80` — le serveur web sur le serveur SSH lui-même. Le serveur SSH reste actif au premier plan ; vous voyez l'invite de commande du serveur.

Étape 3 : Connectez-vous via le tunnel

Ouvrez un deuxième terminal sur votre machine locale et tapez :

curl http://localhost:8080

Vous recevez la réponse HTTP du serveur web sur le serveur SSH, sans que le port 80 du serveur doive être accessible depuis l'extérieur.

Étapes : le port forwarding inverse

Le port forwarding inverse est utilisé lorsqu'une partie externe doit accéder à un service sur votre machine locale, alors que vous êtes derrière un pare-feu ou un NAT. L'option `-R` active un port sur le serveur SSH vers un port sur le client.

Étape 4 : Démarrez le forwarding inverse

ssh -R 9000:localhost:3000 user@192.168.1.10

Le serveur SSH écoute désormais sur le port 9000. Le trafic qui y arrive traverse le tunnel SSH vers votre machine locale et aboutit sur `localhost:3000` — par exemple un serveur de développement local. Cette méthode est souvent utilisée pour le support sur site ou le débogage d'applications sur une plateforme de développement locale.

Étape 5 : Testez le tunnel inverse depuis le serveur

curl http://localhost:9000

Exécutez cette commande dans une session SSH sur le serveur lui-même. Vous recevez la réponse du service sur votre machine locale.

Étapes : le port forwarding dynamique

Le port forwarding dynamique crée un proxy SOCKS sur la machine locale. Contrairement au forwarding fixe, où vous spécifiez un hôte et un port précis, le forwarding dynamique achemine chaque connexion qui arrive via le port SOCKS à travers le tunnel SSH. La destination est déterminée par le client lui-même.

Étape 6 : Démarrez le forwarding dynamique

ssh -D 1080 user@192.168.1.10

Le client SSH exécute désormais un proxy SOCKS5 sur le port local 1080. Vous pouvez configurer ce proxy dans un navigateur ou l'utiliser avec des outils comme `curl` :

curl --socks5-hostname localhost:1080 http://example.com

Cette technique est pratique pour naviguer en toute sécurité via un serveur externe ou pour atteindre plusieurs services internes sans configurer de port forwarding à l'avance.

Configuration et limitations

Le client SSH lit sa configuration dans `ssh_config` ; le serveur dans `sshd_config`. Par défaut, le port forwarding est autorisé. Les administrateurs peuvent le limiter ou le désactiver pour empêcher le tunneling vers des services internes.

L'option serveur la plus importante est `AllowTcpForwarding`. Si vous la définissez sur `no`, le serveur refuse toutes les demandes de forwarding :

<h2>/etc/ssh/sshd_config</h2>
AllowTcpForwarding no

Après une modification, redémarrez le démon SSH :

sudo systemctl restart sshd

Le démon `sshd` écoute par défaut sur le port 22 et démarre automatiquement au démarrage du système, via systemd ou `/etc/init.d/ssh`.

Vérification

Vérifiez que le tunnel est actif avec :

ss -tlnp | grep -E '8080|9000|1080'

Ceci montre les ports en écoute sur votre système local. Pour une vérification plus approfondie de la connexion SSH elle-même :

ssh -v -L 8080:localhost:80 user@192.168.1.10

Le drapeau `-v` affiche une sortie de débogage détaillée, y compris l’établissement du tunnel.

Problèmes fréquents

1. « bind: Address already in use »

Le port local est déjà occupé. Choisissez un autre port ou fermez le processus qui utilise le port :

sudo lsof -i :8080

2. « channel 0: open failed: connect failed »

Le serveur SSH ne peut pas atteindre le nom d’hôte distant ou le port distant. Vérifiez que le service tourne sur le serveur et que le nom d’hôte distant est correct vu depuis le serveur. Utilisez `localhost` si le service tourne sur le serveur SSH lui-même.

3. « Permission denied (publickey) »

Le serveur n’accepte pas l’authentification par mot de passe. Utilisez des clés SSH au lieu de mots de passe — cela augmente aussi la sécurité de vos tunnels. Générez une paire de clés :

ssh-keygen -t ed25519
ssh-copy-id user@192.168.1.10

Considérations de sécurité

Un tunnel mal configuré peut exposer involontairement des services internes. Gérez soigneusement les paramètres dans `sshd_config`. Utilisez des clés SSH au lieu de mots de passe pour l’authentification. Envisagez de définir explicitement `AllowTcpForwarding`, même si vous souhaitez autoriser le forwarding — la valeur par défaut peut varier selon la distribution.

La norme SSH est le résultat d’un développement collectif au sein de la communauté Internet. Les spécifications incluent les RFC 4250 à 4256, qui forment ensemble la base officielle des implémentations SSH modernes comme OpenSSH. Un inventeur exact ou un lieu d’origine n’est pas documenté ; la norme actuelle a grandi grâce à des années de contributions de divers auteurs et organisations.

Les trois formes de forwarding — local, inverse et dynamique — couvrent la plupart des scénarios pratiques. Le forwarding local pour atteindre des services internes, le forwarding inverse pour exposer des services locaux vers l’extérieur, et le forwarding dynamique pour un accès flexible via un proxy SOCKS. Le choix de la forme dépend de la direction dans laquelle le trafic doit circuler et si la destination est connue à l’avance.

La force du tunneling SSH réside dans sa simplicité : vous n’avez besoin d’aucun logiciel supplémentaire, seulement d’une connexion SSH fonctionnelle. Mais cette simplicité invite aussi à la négligence — un tunnel que vous n’utilisez plus doit être fermé. Un tunnel inverse oublié peut exposer un environnement de développement à tout le réseau du serveur. Le contrôle de vos tunnels est aussi important que la capacité de les ouvrir.