Le proxy sans agent : remplacer les clients téléchargeables par SSH

Comment une seule commande SSH remplace des démons CLI encombrants — et ce que votre équipe InfoSec doit savoir à ce sujet.

Le problème : lorsque votre ordinateur portable ne vous laisse rien installer

Les points d’accès d’entreprise modernes sont verrouillés plus que jamais. Les plateformes de détection et réponse d’extrémité (EDR) comme CrowdStrike Falcon, SentinelOne, et Microsoft Defender for Endpoint détectent et bloquent activement l’installation de binaires non signés ou non reconnus — y compris les CLIs de tunneling populaires écrits en Go ou Rust. Les politiques de liste blanche d’applications signifient que même les outils de développement légitimes peuvent être mis en quarantaine avant même leur exécution.

Pour un développeur souhaitant partager une application React en local pour une revue rapide ou exposer un endpoint webhook pour tester une intégration Stripe, cela crée un paradoxe frustrant : les outils qui résoudraient le problème sont eux-mêmes bloqués par la politique.

La solution élégante est déjà présente sur chaque machine de développeur, approuvée par tous les départements IT du monde : OpenSSH.

Qu’est-ce que le tunneling localhost sans agent ?

Le tunneling sans agent (aussi appelé tunneling zero-install) consiste à exposer un port local à Internet public en utilisant rien d’autre que le client SSH natif déjà intégré à votre système d’exploitation — pas de binaire téléchargé, pas de package npm, pas de permissions d’installation élevées requises.

La technique repose sur le drapeau Remote Port Forwarding (-R) de SSH, qui indique à un serveur distant d’accepter le trafic public et de le relayer via un tunnel SSH chiffré vers un port sur votre machine locale. Le serveur relais distant agit comme le point d’extrémité accessible publiquement ; votre ordinateur portable agit comme l’origine cachée.

L’architecture ressemble à ceci :

[ Utilisateur Internet Public ]
         │
         ▼ (Requête HTTPS)
[ Serveur Relais ] (par ex., *.pinggy.io)
         │
         │ Tunnel SSH inversé (Port 443)
         ▼
[ Votre Ordinateur Portable ] (Client OpenSSH natif)
         │
         ▼ (Routage interne)
[ Application Locale ] (par ex., Node.js sur localhost:3000)

Analyse de la commande en une ligne

Voici une commande typique de tunnel sans installation :

ssh -p 443 -R0:localhost:3000 free@a.pinggy.io

Chaque drapeau a une fonction spécifique :

ssh — Lance le binaire OpenSSH natif. Pas besoin de téléchargement ; il est livré avec macOS, toutes les distributions Linux majeures, et Windows ¹⁰⁄₁₁.
-p 443 — Se connecte via le port 443 au lieu du port SSH par défaut 22. C’est un choix d’ingénierie délibéré : les pare-feux d’entreprise autorisent presque universellement le trafic HTTPS sortant sur 443, alors que le port 22 est souvent bloqué pour les stations de travail. La poignée de main SSH passe par le même canal que le trafic web normal.
-R — Active le Remote Port Forwarding. Cela indique au serveur d’ouverture un port et de relayer le trafic vers vous.
0:localhost:3000 — Le 0 demande au relais d’attribuer dynamiquement un port ou sous-domaine public disponible. localhost:3000 indique où le relais doit envoyer ce trafic sur votre machine.
free@a.pinggy.io — L’adresse du serveur relais, avec free comme préfixe de nom d’utilisateur (Pinggy utilise ce champ pour l’injection de paramètres, expliqué plus tard).

Lors de l’exécution, le serveur relais fournit une URL publique générée automatiquement — quelque chose comme https://rkyxl-12-34-56.a.pinggy.link — affichée directement dans votre terminal et prête à être partagée.

Pourquoi le port 443 est la clé

La plupart des pare-feux d’entreprise sont configurés pour bloquer le port 22 sortant depuis les stations de travail pour empêcher la gestion à distance non autorisée. Le port 443 est réservé au trafic web HTTPS et est presque toujours ouvert — le bloquer casserait la navigation web normale pour toute l’organisation.

En utilisant SSH sur le port 443, la poignée de main initiale du tunnel est indiscernable d’une connexion TLS standard à un serveur web. Les appareils d’Inspection Profonde de Paquets (DPI) le voient comme du trafic HTTPS chiffré à volume élevé. Comme le note la recherche en sécurité de JUMPSEC Labs, de nombreux environnements d’entreprise autorisent encore le SSH sortant, même lorsqu’ils pensent ne pas le faire, car surveiller SSH comme un binaire “qui tourne en permanence” (LOLBIN) n’est pas une pratique standard pour les équipes de sécurité axées sur la détection de malware.

Note importante pour les équipes de sécurité : cette double utilisation est détaillée dans la section Sécurité ci-dessous.

Les principales plateformes de tunneling sans agent en 2026

Parce que chaque utilisateur utilise le même binaire SSH standard, la différenciation entre services zero-install repose entièrement sur les capacités du serveur relais. Voici les plateformes à connaître :

1. Pinggy

Pinggy s’est imposé comme l’option sans agent la plus complète en fonctionnalités, sans installation. Une seule commande SSH lance une interface terminale interactive (TUI) complète avec des compteurs de requêtes en temps réel, des statistiques de trafic en direct, et un code QR affiché directement dans le terminal — utile pour tester immédiatement la réactivité mobile.

Fonctionnalités clés : - Support des protocoles HTTP, HTTPS, TCP, et UDP (le tunneling UDP n’est offert ni par ngrok ni par Localtunnel) - Un débogueur web intégré accessible à http://localhost:4300 lorsqu’il est combiné avec un forwarding de port local (-L 4300:localhost:4300), permettant d’inspecter les en-têtes HTTP, les payloads, et de rejouer des requêtes - Contrôle avancé du trafic injecté via la chaîne de caractères du nom d’utilisateur SSH (authentification, liste blanche IP, overrides CORS, en-têtes personnalisés — tout sans toucher à un fichier de configuration) - Sessions du niveau gratuit coupées après 60 minutes ; les niveaux payants commencent à 3$/mois pour des tunnels persistants

Fonctionne confirmé (au moment des tests de mars 2026 par l’équipe Hermes d’NousResearch) : une seule commande SSH génère instantanément des URLs publiques HTTP et HTTPS, avec certificats Let’s Encrypt gratuits, sans besoin de compte.

Avertissement performance : Lors d’un benchmark de transfert de fichier de 100 Mo réalisé par LocalCan en 2025, Pinggy a délivré environ 1,10 Mo/sec (8,81 Mbps), ce qui était le plus lent parmi les outils testés. Cela est principalement dû au problème TCP-over-TCP inhérent au tunneling SSH : la couche TCP de l’application interne et le tunnel SSH externe gèrent leur propre contrôle de congestion, et une perte de paquet sur la couche externe peut bloquer la connexion interne. Pour tester des webhooks et partager des UI, cela pose rarement problème ; pour de gros transferts, c’est différent.

2. localhost.run

Pour une simplicité absolue, localhost.run offre une alternative fiable, sans configuration, avec peu ou pas d’overhead visuel :

ssh -R 80:localhost:3000 nokey@localhost.run

Le serveur retourne un lien HTTPS propre et reste silencieusement en arrière-plan — idéal pour scripts bash automatisés, validations CI/CD, et situations où l’espace terminal doit être conservé. Il supporte uniquement HTTP et HTTPS (pas TCP ni UDP), et fonctionne sur tout OS avec SSH. Aucun compte n’est requis pour commencer à tunneler immédiatement.

3. Serveo

Serveo est une option gratuite bien établie, notable pour une fonctionnalité : vous pouvez demander un sous-domaine spécifique directement dans la commande :

ssh -R mysubdomain:80:localhost:5000 serveo.net

Si le sous-domaine est disponible, le serveur le lie immédiatement. Utile pour des URLs webhook persistantes en développement. En tant que ressource gratuite soutenue par la communauté, la disponibilité peut fluctuer sous charge comparée à une infrastructure commerciale — à garder en tête pour tout ce qui est sensible au temps.

4. Localtonet (mode SSH)

Localtonet a commencé comme un outil de tunneling multi-protocole orienté client, mais a développé un point d’entrée SSH dédié sans agent. Les utilisateurs configurent un tunnel via un tableau de bord web, qui fournit une commande SSH authentifiée par token. Cela relie les exigences de contrôle d’entreprise à une exécution sans agent.

En janvier 2026, Localtonet est tarifé à 2$ par tunnel par mois et offre une redondance multi-régions, support UDP, intégration SSO, et 99,9% de disponibilité — ce qui en fait l’option la plus complète pour les équipes nécessitant plus qu’une URL de démo rapide.

Comparaison avec les outils traditionnels

Fonctionnalité	Pinggy	localhost.run	Serveo	ngrok	Cloudflare Tunnel
Installation requise	Aucune (SSH)	Aucune (SSH)	Aucune (SSH)	Binaire CLI	Daemon `cloudflared`
Support des protocoles	HTTP, HTTPS, TCP, UDP	HTTP, HTTPS	HTTP, HTTPS, TCP	HTTP, HTTPS, TCP	HTTP, HTTPS, gRPC
Tableau de bord terminal	Oui (TUI interactif)	Non (texte seul)	Non (texte seul)	Oui (CLI personnalisé)	Non (console cloud)
Inspecteur UI web	Oui (via port local)	Non	Non	Oui (port localhost)	Oui (console cloud)
Domaines personnalisés	Niveaux payants	Niveaux payants	Oui (si disponible)	Niveaux payants	Oui (gratuit via DNS)
Limite gratuite	Sessions de 60 min	Illimité	Illimité	1 Go/mois	Bande passante illimitée
Support UDP	Oui	Non	Non	Non	Non
Débit (test 100 Mo)	~1,10 Mo/sec	Non mesuré	Non mesuré	~0,84 Mo/sec	~3,47 Mo/sec

Tarification ngrok début 2026 : niveau gratuit (1 Go/mois, domaines aléatoires, avertissement de session), personnel à 8$/mois (5 Go, 1 domaine persistant), Pro à 20$/mois (15 Go, configuration avancée, équilibrage de charge). Cloudflare Tunnel reste entièrement gratuit pour HTTP/HTTPS sans limite de bande passante, ce qui en fait une option à valeur exceptionnelle pour les équipes déjà dans l’écosystème Cloudflare — mais il faut installer le daemon cloudflared.

Fonctionnalités avancées sans client : injection de paramètres via le nom d’utilisateur SSH

Une idée reçue courante est que passer en mode sans agent signifie perdre l’accès à des fonctionnalités avancées comme l’authentification, la manipulation d’en-têtes, et le contrôle CORS. L’équipe technique de Pinggy a résolu cela en utilisant une fonctionnalité du protocole SSH que la plupart des développeurs négligent : le champ du nom d’utilisateur SSH peut contenir des chaînes arbitraires.

Puisque le protocole SSH permet n’importe quelle chaîne comme nom d’utilisateur, Pinggy analyse cette chaîne sur leurs nœuds de bord pour appliquer dynamiquement des configurations de trafic avant que les paquets n’entrent dans le tunnel. Vous transmettez vos paramètres en les séparant par +.

Authentification de base

Verrouillez une URL publique derrière des identifiants utilisateur/mot de passe — utile pour exposer des outils internes à des parties externes :

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

L’extrémité de Pinggy intercepte les requêtes entrantes et affiche une invite d’authentification HTTP Basic standard dans le navigateur. Votre serveur local ne reçoit jamais de requête non authentifiée.

Liste blanche IP (CIDR)

Restreignez l’accès à une plage IP spécifique — par ex., l’IP de sortie VPN de votre entreprise :

ssh -p 443 -R0:localhost:3000 "w:192.0.2.0/24+free@a.pinggy.io"

Injection d’en-tête HTTP personnalisé

Utile pour simuler des environnements spécifiques, contourner des vérifications API gateway, ou valider des signatures webhook :

ssh -p 443 -R0:localhost:3000 "a:X-Environment:Staging+free@a.pinggy.io"

Override CORS global

Lors des tests de microservices provenant de différentes origines et où le blocage cross-origin empêche l’exécution frontend :

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

Les paramètres peuvent être chaînés. Un tunnel avec authentification de base, CORS activé, et en-tête personnalisé ressemble à :

ssh -p 443 -R0:localhost:3000 "b:admin:pass+co+a:X-Environment:Staging+free@a.pinggy.io"

Cela déplace toute la logique de routage et de sécurité sur des serveurs d’extrémité, contrôlés entièrement via l’analyse de chaîne dans la poignée de main SSH.

Gérer des proxies restrictifs

Si votre réseau bloque aussi le port 443 sortant, ou exige que tout le trafic passe par un proxy HTTP, Pinggy documente une solution avec ncat et openssl :

ssh -p 443 -R0:localhost:4000 \
  -o ProxyCommand="ncat --proxy-type http --proxy 192.168.2.2:3128 %h %p" \
  a.pinggy.io

Cela fait passer le tunnel SSH via votre proxy HTTP d’entreprise, rendant cela viable même dans des environnements avec filtrage sortant agressif.

La perspective sécurité : ce que les équipes InfoSec doivent savoir

Le tunneling sans agent est fondamentalement à double usage. Les mêmes propriétés qui le rendent fluide pour les développeurs — trafic chiffré sur le port 443, pas de binaire à signaler, pas d’événements d’installation à enregistrer — en font une voie potentielle d’exfiltration de données si mal utilisé ou exploité.

Ce que les développeurs gagnent

Du point de vue du transit de données, les proxies sans agent sont réellement sécurisés. Le lien entre la machine du développeur et le serveur relais est enveloppé dans un chiffrement SSH (AES-GCM ou ChaCha20-Poly1305). Le trafic côté public circule via HTTPS standard jusqu’au point d’extrémité du fournisseur, où il est déchiffré et rechiffré via SSH avant d’arriver sur la machine locale. Sur des réseaux locaux ouverts ou compromis — Wi-Fi de café, réseaux d’hôtel de conférence — les payloads de code d’entreprise ne peuvent pas être sniffés ou interceptés.

Ce que les équipes de sécurité doivent surveiller

Parce que le trafic circule dans un wrapper SSH chiffré sur le port 443, les appareils DPI traditionnels le classent comme du trafic HTTPS générique. Il n’y a pas d’événement d’installation binaire, pas de modification de registre, pas de processus avec un nom inhabituel. Le seul signal est une connexion SSH sortante vers un domaine inconnu.

Approches de gouvernance pratiques que les équipes de sécurité adoptent :

Liste blanche de l’infrastructure relais. Plutôt que d’essayer de bloquer tout tunneling SSH (ce qui risquerait de bloquer des usages légitimes), les entreprises collaborent avec des fournisseurs zéro-install commerciaux comme Pinggy Pro ou Localtonet Enterprise. L’organisation configure un domaine personnalisé dédié (par ex., *.tunnels.company.com) et liste dans le pare-feu les IPs statiques de ces nœuds relais spécifiques. Les fournisseurs relais non autorisés sont bloqués par défaut.

Application de clés SSH. Les équipes de sécurité exigent que tout tunnel SSH initié depuis un actif d’entreprise s’authentifie avec une paire de clés SSH autorisée liée au compte d’un employé dans un fournisseur d’identité (IdP). Cela garantit une traçabilité complète : quel compte a ouvert le tunnel, quand, et quelle quantité de bande passante a été transférée.

Adopter des durées éphémères. La version gratuite de Pinggy impose des coupures automatiques toutes les 60 minutes. Les équipes InfoSec peuvent voir cela comme une fonctionnalité plutôt qu’une limitation, en établissant une politique selon laquelle les tunnels sont des actifs éphémères — créés à la demande pour une tâche de débogage spécifique, puis détruits immédiatement après. Cela réduit la surface d’attaque accessible aux scanners internet et acteurs malveillants persistants.

Détection comportementale. Les outils de sécurité comme Zeek et les plateformes EDR modernes avec règles comportementales SSH peuvent être configurés pour alerter sur des modèles de port-forwarding inhabituels — par exemple, une station de travail établissant un forwarding -R vers un hôte externe, ou des sessions SSH à haut débit prolongées vers des domaines non d’entreprise. C’est une stratégie de détection plus durable que de tenter de bloquer SSH totalement.

Quand utiliser quoi : un cadre de décision

Utilisez Pinggy si : vous avez besoin de quelque chose en moins de 30 secondes, sans installation, avec un inspecteur de requêtes, support UDP, ou pour partager un QR code pour tests mobiles.

Utilisez localhost.run si : vous automatisez des scripts, validez des pipelines CI/CD, ou souhaitez un processus discret en arrière-plan sans surcharge de tableau de bord terminal.

Utilisez Serveo si : vous avez besoin d’un sous-domaine mémorable et persistant durant un sprint de développement, et pouvez tolérer des interruptions occasionnelles.

Utilisez Localtonet si : vous faites partie d’une équipe, avez besoin de fiabilité multi-régions, d’intégration SSO, ou support UDP avec un SLA sérieux.

Utilisez Cloudflare Tunnel si : vous êtes déjà dans l’écosystème Cloudflare, avez besoin de fiabilité en production, de bande passante illimitée en HTTP/HTTPS, et ne voyez pas d’inconvénient à installer cloudflared. En 2025, il a atteint 3,47 Mo/sec en débit — le plus rapide parmi les options testées.

Utilisez ngrok si : vous souhaitez une large écosystème d’intégrations et êtes prêt à payer pour la persistance et le volume. Son débit de 0,84 Mo/sec est le plus lent parmi les principales options, malgré sa popularité.

Conclusion

Le cas du tunneling sans installation en 2026 ne se limite pas à la commodité — il s’agit de travailler avec l’architecture de sécurité que les entreprises ont construite plutôt que de lutter constamment contre elle. Un binaire SSH natif est déjà de confiance. Il ne génère pas d’événements d’installation. Il ne requiert pas de permissions élevées. Et lorsqu’il est tunnellé sur le port 443, il passe à travers les filtres d’entreprise sans friction.

Les plateformes bâties sur ce modèle — Pinggy, localhost.run, Serveo, Localtonet — ont atteint un niveau de maturité où elles égalent ou surpassent les fonctionnalités orientées développeur des clients CLI traditionnels. L’ajout de l’injection de paramètres pour l’authentification, CORS, et la manipulation d’en-têtes signifie que la chaîne du nom d’utilisateur dans une seule commande SSH peut reproduire ce qui nécessitait auparavant un fichier de configuration complet et un démon en fonctionnement.

Pour les équipes InfoSec et NetOps, la bonne réponse n’est pas de bloquer SSH (ce qui pose plus de problèmes qu’il n’en résout), mais de structurer la gouvernance autour d’une infrastructure relais approuvée, d’une authentification par clés, d’une traçabilité, et d’une détection comportementale. Les outils existent ; les cadres évoluent.

Pour le développeur face à un point d’accès verrouillé : cessez de lutter contre les permissions d’installation. Le client de tunneling le plus puissant dont vous avez besoin est déjà sur votre machine.

ssh -p 443 -R0:localhost:3000 free@a.pinggy.io

C’est tout.

Dernière mise à jour : mai 2026. Tarification et détails des fonctionnalités pour Pinggy, ngrok, Cloudflare Tunnel, et Localtonet vérifiés contre la documentation actuelle et des benchmarks tiers.

Tunneling sans installation en 2026 : Le guide complet pour les proxies localhost sans agent