Quel trafic applicatif un transfert SSH achemine-t-il réellement ?

Le terminal se connecte, l’invite apparaît et tout le monde convient que l’accès SSH fonctionne. Puis un client de base de données sur l’ordinateur portable n’atteint toujours pas l’hôte privé, et la session est mise en cause. Ce qui a été construit est un shell, et c’est l’une des quatre interfaces assez différentes que SSH peut offrir. Nommez d’abord l’interface, puis vérifiez que l’application l’utilise vraiment. L’ordre compte, car chaque interface échoue à sa manière.

Nommez l’interface avant de comparer quoi que ce soit

Le manuel du client OpenSSH distingue quatre mécanismes faciles à confondre. Un shell ou une commande distante s’exécute sur l’hôte SSH. Un transfert local ouvre une socket d’écoute sur le client et établit la connexion suivante depuis le côté distant. Un transfert distant fait l’inverse, en écoutant côté serveur. Le transfert dynamique expose un point de terminaison SOCKS aux programmes qui savent l’utiliser.

• Shell : le programme s’exécute sur la machine distante, rien n’écoute localement.
• Transfert local : votre ordinateur portable a un port, l’hôte distant établit la connexion sortante.
• Transfert distant : le côté distant a un port, le trafic revient vers vous.
• Dynamique : un proxy SOCKS sur le client, utilisé uniquement par les applications qui le comprennent.

Aucun de ces mécanismes n’installe de route. Un programme qui ignore les réglages de proxy, ou parle UDP, ou résout les noms tout seul, n’est pas affecté par une session SSH active. Ce n’est pas un défaut de SSH ; c’est la portée de l’interface que vous avez choisie.

Les transferts local, distant et dynamique diffèrent par qui écoute

La distinction qui tranche la plupart des cas est qui possède la socket d’écoute. Avec un transfert local, le client écoute et l’extrémité distante compose le destinataire, ce qui explique que l’adresse de destination soit résolue du point de vue du serveur. Avec un transfert distant, le serveur écoute et la connexion est ramenée vers votre côté, et c’est ainsi que vous exposez un service local sans le publier directement.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

La première commande lie le port 5432 sur l’ordinateur portable et le transfère vers la base de données telle qu’elle est vue depuis le bastion. La seconde crée un proxy SOCKS sur le port 1080. La troisième commande confirme quels processus écoutent réellement, et c’est la seule preuve que le transfert existe plutôt qu’il n’ait échoué en silence sur un conflit de ports.

Le transfert dynamique mérite son propre avertissement : il ne couvre que les applications qui respectent SOCKS. Un navigateur peut y être pointé, un outil en ligne de commande peut être prié de l’utiliser, mais un pilote de base de données doté de sa propre pile de connexion ne le peut généralement pas. Supposer que tous les programmes de la machine passent désormais par le tunnel est l’erreur la plus courante dans tout ce domaine.

Le mode périphérique tunnel est la seule vraie exception réseau

OpenSSH prend aussi en charge le transfert de périphérique tunnel -w, qui fait passer une interface point à point plutôt qu’un écouteur TCP. C’est un véritable tunnel réseau, et il se configure délibérément, ce n’est pas un effet secondaire de l’ouverture d’un shell.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Il exige les numéros d’interface correspondants disponibles aux deux extrémités, la bonne configuration sur le serveur et suffisamment de privilèges sur le client pour créer le périphérique. Il exige aussi un plan d’adressage et de routage, car une interface nue ne porte aucune politique sur les destinations qui doivent l’utiliser.

Même alors, le tunnel se termine à l’hôte distant. Quelle que soit la protection apportée par le transport SSH, elle s’arrête là, et la connexion suivante est un saut distinct. Une passerelle VPN a la même forme de frontière, ce qui explique que la comparaison doive porter sur la portée et la terminaison plutôt que sur l’outil le plus puissant. Nommer cette frontière à voix haute tranche aussi le débat sur le fait qu’un tunnel « chiffre tout », car il est clair que non.

Vérifiez que votre application utilise l’interface que vous avez construite

La vérification se fait par application, non par session. Un transfert qui fonctionne prouve que le port est lié et que le côté distant peut composer ; il ne prouve pas que le programme qui vous intéresse s’est connecté à travers lui.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

La première commande envoie une requête via le point de terminaison SOCKS avec le nom d’hôte résolu à distance, et la seconde éprouve le port de base de données transféré avec TLS toujours requis. Exécutez les mêmes tests avec le transfert arrêté pour confirmer qu’ils échouent, car un test qui passe dans les deux cas n’a jamais utilisé le tunnel.

Comparez ensuite avec un VPN routé uniquement sur les dimensions qui comptent : quelles destinations sont couvertes, quels protocoles fonctionnent, où la protection s’arrête et qui doit approuver l’accès. Un transfert pour un seul service peut être la réponse plus étroite et meilleure, tandis qu’un VPN est la bonne forme quand de nombreuses applications ont besoin du même chemin réseau. Ni l’un ni l’autre n’accorde tout ce qui est joignable depuis son extrémité distante.