Tunnels HTTP auto-hébergés avec SSH et Nginx : une approche minimaliste
Sommaire
En bref
- Créer des tunnels HTTP temporaires sans dépendre d'un service commercial revient à combiner SSH, Nginx et un peu de hachage MD5.
- L'approche repose sur le redirection SSH (ssh -R) vers un port local, puis utilise Nginx pour router les requêtes HTTPS via un hash d'authentification généré à la volée.
- Une couche de sécurité supplémentaire est ajoutée grâce au module `secure_link` de Nginx, qui valide une signature temporaire plutôt que de laisser le numéro de port comme seul secret.
Ce que dit la source
L'article pose un problème courant : exposer temporairement un service local (par exemple, un brouillon de blog en localhost:8080) à un ami ou un collaborateur pour relecture. Les solutions existantes (ngrok, Cloudflare Tunnels) sont des services SaaS, d'autres outils comme frp nécessitent un client dédié. L'auteur propose de réaliser la même chose en combinant uniquement OpenSSH standard et Nginx, sans logiciel supplémentaire côté client.
- La base du mécanisme utilise ssh -R 0:localhost:8080 pour rediriger un port distant vers votre service local ; OpenSSH alloue un port éphémère à la volée.
- Nginx intercepte les requêtes HTTPS via un pattern de domaine wildcard et les redirige en HTTP local vers le port utilisé, avec proxy_pass http://127.0.0.1:$port.
- Le numéro de port seul comme secret est faible ; l'auteur ajoute un hash MD5 signé avec une clé secrète et un timestamp d'expiration, placé en tant que nom d'utilisateur HTTP Basic Auth.
- Le module ngx_http_secure_link_module valide le hash à chaque requête et rejette les liens expirés (410) ou invalides (401).
- Un script helper déduit le port éphémère en inspectant les processus sshd-session ancêtres et génère automatiquement l'URL complète avec token et expiration.
- DNS wildcard et certificat Let's Encrypt wildcard sont nécessaires ; l'auteur utilise une zone Route 53 pour les défis ACME DNS-01.
- WebSocket et connexions longue durée sont supportés via les directives proxy_http_version, Upgrade et Connection.
Dans les commentaires
Débat partage, penche vers le scepticisme technique.
- Plusieurs commentateurs soulignent des risques de sécurité réels : la première section Nginx (sans le secure_link) permet à un attaquant de scanner les ports locaux sur localhost et contourner les règles firewall, ce qui est un trou critique.
- Des alternatives concurrentes sont mises en avant : sish (serveur SSH spécialisé open source), iroh (relais P2P chiffrés sans port forwarding), et DNTLS (approche sans intermédiaire). Aucune n'est présentée comme uniformément meilleure, mais chacune adresse un aspect différent.
- Un commentateur objecte que pour la plupart des usages personnels, exposer son IP avec un serveur Nginx classique sur le routeur est plus simple et moins fragile que ce tunnel complexe.
- L'approche par certificat client est suggérée comme alternative, avec la limite que les navigateurs mobiles gèrent mal les certificats.
- Un point avancé : utiliser un proxy SOCKS5 SSH évite de hardcoder les ports.
- `*.ssh.luffy.cx` n'est pas auto-hébergé, c'est un sous-domaine tiers ; le commentaire soulève que le terme « self-hosted » peut induire en erreur.
Alternatives citées : sish (serveur SSH open source avec TLS automatique), iroh (relais P2P), DNTLS (tunnel sans intermédiaire), Tailscale, Cloudflare Tunnels, ngrok
Notre lecture
L'approche est techniquement intéressante comme démonstration du principe « on peut réutiliser SSH et Nginx plutôt que de binder une nouvelle dépendance ». Pour qui gère déjà son DNS et son infrastructure Nginx, c'est un gain légitime (zéro client spécifique). En revanche, la sécurité par défaut est fragile sans le module secure_link, et même avec lui, l'exposition d'un service local à un port réseau global reste un pas que beaucoup d'équipes éviteront. Le vrai frein : la plupart des usages réels privilégient les solutions SaaS (ngrok, Cloudflare Tunnels) ou P2P (Tailscale, iroh) pour éviter de configurer du DNS, des certificats et de gérer des secrets. À surveiller surtout si vous êtes en charge d'une infra interne complexe où l'outil s'inscrit dans une pile déjà en place.