Tunnels SSH : redirection de port locale, distante et dynamique

Ce que c'est

Le manuel ssh(1) décrit trois modes de redirection. -L [bind_address:]port:host:hostport écoute sur un port local et redirige chaque connexion, via le canal sécurisé, vers host:hostport tel qu'atteint depuis la machine distante (redirection locale). -R [bind_address:]port:host:hostport écoute sur l'hôte distant et redirige les connexions vers une destination atteignable depuis le client (redirection distante) ; si seul un port est donné, le client agit comme proxy SOCKS pour le côté distant. -D [bind_address:]port ouvre un proxy SOCKS4/5 local dont la destination est décidée par connexion (redirection dynamique). -J destination connecte d'abord via un hôte relais, un raccourci pour ProxyJump. -N n'exécute aucune commande distante, ce que le manuel note comme utile pour ne faire que rediriger des ports. Les sockets Unix peuvent également être redirigées. Le côté à l'écoute est lié selon GatewayPorts ; un bind_address de localhost garde le port local, tandis que * l'ouvre sur toutes les interfaces.

Pourquoi c'est important

Les tunnels atteignent des bases de données, des interfaces d'administration et des API internes délibérément non exposées, sans ouvrir de ports de pare-feu, en utilisant les mêmes clés et les mêmes journaux que le SSH interactif. Ce même mécanisme fait qu'un tunnel lié sans précaution devient un moyen de publier un service interne sur le réseau.

Comment l'appliquer

• Atteindre une base de données sur un réseau privé : ssh -N -L 5433:db.internal:5432 bastion, puis se connecter à localhost:5433.
• Exposer un serveur de développement local à une machine distante : ssh -N -R 8080:localhost:3000 host. Sur le serveur, GatewayPorts dans sshd_config décide si d'autres hôtes peuvent se connecter à ce port ; le réglage par défaut lie les redirections distantes à loopback.
• Naviguer à travers le réseau distant : ssh -N -D 1080 host et pointer le client vers le proxy SOCKS.
• Rebondir via un bastion : ssh -J bastion target, ou ProxyJump dans ~/.ssh/config ; y conserver les redirections sous forme de LocalForward et RemoteForward afin qu'elles soient reproductibles.
• Régler ExitOnForwardFailure yes afin que ssh se termine lorsqu'une redirection demandée ne peut pas être liée, plutôt que de continuer sans elle ; ajouter ServerAliveInterval afin qu'une connexion morte soit remarquée.
• Sur les serveurs, restreindre la redirection avec AllowTcpForwarding (no, local ou remote) pour les comptes qui n'en ont pas besoin.

Pièges

Une redirection qui « fonctionne » peut appartenir à un ancien processus ssh qui détient encore le port ; vérifier les processus à l'écoute avec ss -ltnp. Seul le superutilisateur peut rediriger les ports privilégiés. -R n'ouvre pas le pare-feu distant. ExitOnForwardFailure ne couvre que la mise en place de l'écoute, pas les échecs à atteindre la destination finale. Les tunnels contournent la politique réseau par construction, donc documenter chaque tunnel permanent.