La rébellion "Zero-Install" SSH : contourner les pare-feu d'entreprise avec des tunnels localhost

Entrez dans n’importe quelle société de logiciels d’entreprise en 2026, et vous découvrirez une confrontation silencieuse et persistante entre développeurs et IT d’entreprise. Les développeurs doivent itérer rapidement — partager une application web locale avec QA, tester des webhooks externes de Stripe ou GitHub, prévisualiser un backend mobile tournant sur un laptop. Pendant ce temps, l’IT applique des politiques de réseau zero-trust : trafic entrant bloqué par défaut, trafic sortant surveillé de près.

Pendant des années, la démarche par défaut des développeurs était de télécharger un binaire de tunneling tiers, de l’exécuter, et d’obtenir une URL publique. Avec le durcissement des mesures de sécurité, cela est devenu plus difficile. Introduire un exécutable non approuvé sur un laptop géré est désormais un moyen rapide de déclencher une alerte EDR.

Les développeurs ont donc pivoté vers quelque chose déjà whitelisté partout : le client SSH natif. En utilisant un tunnel SSH inversé, vous pouvez partager un port local avec le monde extérieur sans rien installer. Deux services conçus spécifiquement autour de ce pattern — Pinggy et localhost.run — sont devenus les backends de référence pour cela. Voici comment fonctionne cette technique, comment ces deux services se comparent en 2026, et où le marketing simplifie à l’excès.

Pourquoi les tunnels traditionnels peinent en entreprise

Les outils basés sur un agent installé localement offraient une excellente expérience aux développeurs, mais créaient de vrais problèmes pour les équipes de sécurité :

• Binaries bloqués. Les plateformes EDR comme CrowdStrike ou SentinelOne bloquent systématiquement les exécutables non signés ou non reconnus, et les agents de tunneling tiers tombent dans cette catégorie.
• Privilèges élevés. Certains agents veulent manipuler les interfaces réseau ou fonctionner en tant que service en arrière-plan — ce que la plupart des développeurs sur machines gérées ne peuvent pas faire.
• Trafic non standard. Quelques agents utilisent des protocoles ou ports personnalisés qui sont signalés ou bloqués par l’inspection approfondie des paquets.

Résultat : un développeur devant tester une charge utile webhook pourrait perdre des jours dans un processus d’approbation, pour que le pare-feu bloque la connexion sortante du binaire de toute façon.

La solution : tunnels SSH inversés, expliqués

SSH est préinstallé sur macOS, Linux, et (depuis la mise à jour de Windows 10 en 2018) Windows, et il est fiable pour l’administration serveur. Moins utilisé, mais intégré dans le même protocole, le forwarding de ports distant/reverse — le flag -R.

# Syntaxe classique du tunnel inverse
ssh -R [port distant]:localhost:[port local] user@serveur-distant.com

Au lieu d’ouvrir une brèche entrante dans un pare-feu, un tunnel inverse initie une connexion sortante de votre machine vers un serveur public. Comme la connexion provient de l’intérieur du réseau, les règles NAT et pare-feu étatful classiques la laissent passer sans configuration spéciale. Le serveur distant utilise ensuite cette même connexion pour relayer le trafic vers votre port local.

Sur l’astuce du port 443 : SSH fonctionne normalement sur le port 22, et beaucoup de pare-feu d’entreprise bloquent spécifiquement ce port pour empêcher ce genre de tunneling. Pinggy contourne cela en acceptant aussi les connexions SSH sur le port 443 — celui réservé habituellement pour HTTPS — rendant le trafic beaucoup plus difficile à distinguer du trafic web chiffré ordinaire au niveau du pare-feu. C’est une fonctionnalité documentée du service Pinggy. localhost.run ne documente pas actuellement un équivalent d’écoute SSH sur le port 443 — ses exemples publiés utilisent tous le port SSH standard. Si votre réseau bloque spécifiquement le port 22, cela constitue une différence pratique importante entre les deux, et pas seulement une question de style.

Pinggy vs localhost.run : la comparaison 2026

localhost.run — le minimaliste

La philosophie de localhost.run est “SSH et rien d’autre”. Une commande, une URL, pas de fichier de configuration, pas d’interface TUI.

• Niveau gratuit : Pas besoin de s’inscrire pour un tunnel à durée limitée, et pas de limite de temps pour la session — c’est une offre “gratuit à vie”. L’inconvénient : le domaine gratuit change à chaque nouvelle connexion et il n’y a pas de bande passante prioritaire.
• Niveau payant : Un abonnement Domaine personnalisé (environ 9 $/mois, facturé annuellement) vous donne un domaine stable — soit le vôtre, soit un sous-domaine lhr.rocks — plus une bande passante prioritaire. Les tunnels TLS passthrough (transfert de trafic TLS brut, non décrypté, sur port 443) sont aussi réservés aux domaines personnalisés, non disponibles en gratuit.
• Sécurité : Pas d’authentification Basic intégrée ni de liste blanche IP. Vous devez gérer l’authentification dans votre application ou compter sur une URL difficile à deviner.
• Support protocole : HTTP/HTTPS uniquement en gratuit.

C’est l’outil idéal quand vous voulez une URL en moins de dix secondes et que vous vous fichez qu’elle change à chaque fois.

Pinggy — l’option riche en fonctionnalités

Pinggy a repris la même contrainte “pas de binaire” et a construit un produit nettement plus riche, en utilisant une astuce intelligente : SSH permet de passer une chaîne arbitraire comme nom d’utilisateur, et l’edge de Pinggy analyse cette chaîne pour y extraire des tokens et mots-clés avant même que le tunnel ne soit établi.

• Niveau gratuit : Les sessions durent 60 minutes par connexion (reconnexion donnant un nouveau sous-domaine aléatoire), avec bande passante illimitée et URLs HTTP et HTTPS instantanés via Let’s Encrypt.
• Niveau payant : Pinggy Pro tourne autour de 2,50 à 3 $/mois pour un sous-domaine persistant, domaines personnalisés, et fonctionnalités d’équipe — bien moins cher que la plupart des concurrents.
• Support protocole : HTTP(S), TCP, UDP, et tunnels TLS — TCP et TLS disponibles même en gratuit.
• Web Debugger : En ajoutant -L4300:localhost:4300 à la commande SSH, vous redirigez l’inspecteur de requêtes/réponses intégré de Pinggy vers localhost:4300 dans votre navigateur, et il expose une petite API locale (/urls, /ipwhitelist) pour automatiser.
• Auth à la périphérie : Auth Basic, liste blanche IP, et manipulation en direct des en-têtes HTTP sont configurés en ajoutant des mots-clés dans la chaîne de nom d’utilisateur SSH — pas besoin de proxy local ni de logiciel supplémentaire.

Le verdict n’a pas beaucoup changé en 2026 : localhost.run gagne pour la simplicité “donne-moi une URL maintenant” ; Pinggy l’emporte quand vous avez besoin de TCP/UDP, d’inspection de requêtes, ou d’auth à la périphérie, et que vous êtes prêt à vous reconnecter toutes les heures en version gratuite.

Étape par étape : partage localhost sans installation

Scénario 1 — Partage rapide avec localhost.run

Vous avez une app React sur le port 3000 et souhaitez la montrer immédiatement.

ssh -R 80:localhost:3000 localhost.run

Cela redirige le tunnel public vers votre port local 3000 et affiche une URL HTTP et HTTPS.

Scénario 2 — Tunnel riche en fonctionnalités avec Pinggy

Vous avez une API Node sur le port 8080 et devez contourner un pare-feu d’entreprise tout en inspectant les payloads webhook entrants.

ssh -p 443 -R0:localhost:8080 -L4300:localhost:4300 free@a.pinggy.io

• -p 443 — se connecte via le port 443 pour que la poignée de main SSH se fonde dans le trafic HTTPS normal.
• -R0:localhost:8080 — demande à Pinggy d’attribuer un sous-domaine public aléatoire routé vers le port local 8080.
• -L4300:localhost:4300 — redirige le Web Debugger de Pinggy vers votre machine pour inspecter les requêtes à http://localhost:4300.
• free@a.pinggy.io — se connecte au niveau gratuit de Pinggy.

Scénario 3 — Sécuriser le tunnel avec Auth Basic

Parce que Pinggy lit la chaîne de nom d’utilisateur SSH comme une série de mots-clés, vous pouvez injecter une authentification HTTP Basic directement à la périphérie, avant que le trafic n’atteigne votre ordinateur :

ssh -p 443 -R0:localhost:3000 "b:admin:supersecret+free@a.pinggy.io"

b:admin:supersecret est le mot-clé documenté pour l’auth Basic de Pinggy (nom d’utilisateur et mot de passe ne peuvent pas contenir de deux-points). Les visiteurs voient une invite d’authentification standard du navigateur ; ceux sans les identifiants ne parviennent jamais à votre machine.

Scénario 4 — Passer un proxy HTTP d’entreprise

Si votre réseau route tout le trafic sortant via un proxy HTTP explicite — ce qui signifie que même le port 443 SSH échoue directement — encapsulez la connexion avec ProxyCommand :

ssh -p 443 -R0:localhost:3000 \
  -o ProxyCommand="ncat --proxy-type http --proxy proxy.corporate.local:3128 %h %p" \
  free@a.pinggy.io

Cela tunnelise la poignée de main SSH elle-même via le proxy d’entreprise en tant que requête HTTP CONNECT, ce qui est une méthode standard et largement utilisée (ncat/ProxyCommand) pour cette situation.

Quoi de neuf en 2026 : au-delà du SSH brut

La commande ssh -R brute fonctionne toujours comme décrit ci-dessus, mais Pinggy a construit davantage autour cette année, ce qui vaut la peine de connaître :

• Un CLI dédié (npm install -g pinggy, ou l’équivalent pour d’autres gestionnaires de paquets) qui encapsule le même protocole SSH mais ajoute une interface TUI plus conviviale, des configs de tunnels sauvegardées, et un support de reconnexion automatique — tout en ne nécessitant pas de téléchargement binaire séparé en dehors d’un gestionnaire de paquets déjà utilisé.
• SDK Node.js et Python pour démarrer et gérer des tunnels de façon programmatique depuis vos scripts ou CI, plutôt que de passer par ssh en ligne de commande.
• Une intégration officielle avec un agent IA — Pinggy documente désormais un pattern Skill/MCP-server pour permettre à des agents IA de créer et gérer des tunnels pour un développeur, reflétant la tendance à piloter l’outillage local par des agents plutôt que par des commandes tapées.

Rien de tout cela ne change l’argument principal — c’est toujours zéro-install au moment de l’utilisation — mais cela montre que le pattern “SSH comme backend de tunneling” a bien mûri, dépassant la simple astuce.

Implications de sécurité de la rébellion

Les équipes de sécurité ont des sentiments mitigés face à cette tendance, et c’est compréhensible.

D’une part, s’appuyer sur SSH natif est probablement plus sécurisé que de laisser les développeurs télécharger des binaires tiers non vérifiés — la cryptographie est standard au niveau OS SSH, et il n’existe pas d’agent propriétaire pouvant agir comme un cheval de Troie.

D’autre part, la facilité à contourner les restrictions sortantes crée un problème de shadow-IT. Si un développeur tunnelise une base de données locale non authentifiée ou un environnement de développement contenant des données clients réelles, il a contourné les contrôles périmétriques de l’entreprise — intentionnellement ou non.

Bonnes pratiques pour un tunneling responsable

• Ne pas exposer de vraies données. Utilisez des données simulées dans les environnements locaux que vous tunnelisez.
• Toujours authentifier à la périphérie. Utilisez l’auth Basic de Pinggy, la liste blanche IP, ou les tokens Bearer plutôt que de compter sur une URL difficile à deviner.
• Fermez les tunnels inactifs. Ctrl+C dès que vous avez fini de tester.
• Connaître la limite de performance. Le tunneling SSH inversé est du TCP sur TCP, ce qui peut souffrir du problème bien connu du “TCP meltdown” en cas de perte de paquets — acceptable pour les API et interfaces, pas idéal pour le transfert de gros fichiers.

Conclusion

La comparaison Pinggy vs localhost.run revient en réalité à une opposition de philosophies : minimalisme absolu versus ensemble de fonctionnalités plus complet, tous deux basés sur la même astuce de tunnel inversé SSH vieille de plusieurs décennies, et tous deux véritablement sans binaires. Que vous ayez besoin de contourner un pare-feu d’entreprise pour tester un webhook Stripe ou simplement donner un lien à un client pour dix minutes, l’outil est déjà dans votre terminal.

---

Changelog (vérification et mise à jour)

• Corrigé/clarifié : L’idée initiale laissait penser que les deux services contournaient les pare-feu via le port 443 de façon équivalente. La documentation de Pinggy indique explicitement son écoute SSH sur le port 443 ; celle de localhost.run ne mentionne que le port SSH standard, donc elle ne bénéficie pas du même avantage documenté contre les réseaux bloquant le port 22.
• Vérifié comme exact : La syntaxe du -R reverse-tunnel ; la commande ssh -R 80:localhost:3000 localhost.run (correspondant à l’exemple officiel de localhost.run) ; le flag -L4300:localhost:4300 pour le Web Debugger de Pinggy et sa syntaxe b:user:pass pour l’auth Basic (confirmé dans la documentation actuelle de Pinggy) ; la durée de 60 minutes pour la session gratuite de Pinggy ; la performance TCP-over-TCP du “meltdown”.
• Ajouté : Détail sur les prix actuels — Pinggy Pro (~2,50 à 3 $/mois) contre le plan Domaine personnalisé de localhost.run (~9 $/mois, facturé annuellement) ; la limite de session sans temps en gratuit de localhost.run (contrairement à Pinggy) ; le fait que les tunnels TLS passthrough de localhost.run sont réservés aux domaines personnalisés, pas en gratuit.
• Ajouté (nouvelle section) : La CLI de Pinggy en 2026, SDK Node.js/Python, et son intégration documentée avec un agent AI — aucune de ces fonctionnalités n’existait dans la version initiale.
• Retiré : Les artefacts de métadonnées/formatage en ligne du document original ; standardisé en Markdown propre.