Exposez vos services locaux
en une commande SSH

1Démarrage rapide

Une seule commande. Aucun compte, aucun client à installer — juste votre OpenSSH.

ssh -4 -p 443 -R 80:localhost:3000 localvhost.com
# → https://<aléatoire>.localvhost.com pointe vers votre localhost:3000

2Tunnel HTTP

Exposez n'importe quel serveur web local. Le port 80 demande un sous-domaine HTTPS.

# app locale sur le port 3000
ssh -4 -p 443 -R 80:localhost:3000 localvhost.com

# port local différent (ex: 5000)
ssh -4 -p 443 -R 80:localhost:5000 localvhost.com

3Sous-domaine personnalisé

Préfixez par le nom souhaité pour obtenir une URL stable et mémorisable.

ssh -4 -p 443 -R monapp:80:localhost:3000 localvhost.com
→ https://monapp.localvhost.com

4Tunnels TCP directs

Pour les services non-HTTP (bases de données, SSH, VNC…), exposez-les sur le port de votre choix — n'importe quel port de 1024 à 65535. Le port demandé est honoré tel quel : demandez 5432, vous obtenez localvhost.com:5432.

# MySQL / MariaDB — exposé sur le MÊME port
ssh -4 -p 443 -R 3306:localhost:3306 localvhost.com       # → localvhost.com:3306

# PostgreSQL
ssh -4 -p 443 -R 5432:localhost:5432 localvhost.com       # → localvhost.com:5432

# Redis
ssh -4 -p 443 -R 6379:localhost:6379 localvhost.com

# SSH distant (port au choix)
ssh -4 -p 443 -R 2022:localhost:22 localvhost.com         # puis: ssh -p 2022 user@localvhost.com

🖥️ RDP sans port — rdp.localvhost.com dans mstsc

Pour le Bureau à distance, connectez-vous avec mstsc en tapant simplement un nom — sans indiquer de port (mstsc vise 3389 par défaut). Avec un poste sur le port 3389, le serveur relaie les octets à l'identique (verbatim), TLS + NLA de bout en bout : mode prouvé avec un vrai mstsc. Pour plusieurs postes, donnez à chacun un port dédié (relais verbatim lui aussi) — voir ci-dessous.

1. Pour le poste principal, ouvrez un tunnel nommé sur le port 3389 depuis une machine ayant accès au poste Windows. Dans mstsc, vous taperez juste rdp.localvhost.com — sans port.
2. Pour chaque poste supplémentaire, choisissez un port dédié (33892, 33893…) : dans mstsc, vous taperez rdp2.localvhost.com:33892 (avec le port). Un poste = un port — c'est le PORT qui aiguille, le nom est mémotechnique.
3. Dans mstsc (Connexion Bureau à distance), saisissez l'adresse (sans port pour le poste sur 3389, avec le port dédié pour les autres) — ou téléchargez le raccourci .rdp déjà configuré, ci-dessous.
4. À la 1ʳᵉ connexion, Windows affiche un avertissement de certificat : c'est normal (voir plus bas), cliquez sur « Se connecter quand même ».

# Poste principal → nom « rdp » sur 3389 (RDP interne 192.168.1.5:3389)
ssh -4 -p 443 -R rdp:3389:192.168.1.5:3389 localvhost.com        # → mstsc : rdp.localvhost.com (SANS port)

# Poste supplémentaire → PORT DÉDIÉ 33892 (RDP interne 192.168.1.7:3389)
ssh -4 -p 443 -R rdp2:33892:192.168.1.7:3389 localvhost.com     # → mstsc : rdp2.localvhost.com:33892

5Services TLS partagés — un port, plusieurs backends (SNI)

Plusieurs services TLS (HTTPS internes, API mTLS, TLS natif) partagent un seul port public : le serveur les aiguille par le nom d'hôte (SNI) de leur poignée de main, exactement comme le RDP. La lecture est passive → le TLS/mTLS reste de bout en bout, chaque service garde son propre certificat, le serveur ne déchiffre jamais rien.

# Service A (HTTPS interne) → nom « app1 », sur le port TLS partagé 9443
ssh -4 -p 443 -N -R app1:9443:192.168.1.10:443 localvhost.com   # → app1.localvhost.com:9443

# Service B (autre HTTPS interne) → nom « app2 », MÊME port
ssh -4 -p 443 -N -R app2:9443:192.168.1.11:443 localvhost.com   # → app2.localvhost.com:9443

# chaque nom atteint SON backend, avec SON certificat
curl https://app1.localvhost.com:9443/   # → 192.168.1.10:443 (cert du service A)
curl https://app2.localvhost.com:9443/   # → 192.168.1.11:443 (cert du service B)

6Quel mécanisme pour quel service ?

Un seul critère décide : qui parle en premier, et où se trouve le nom d'hôte. Le serveur ne peut router une connexion que s'il trouve un identifiant dans ses premiers octets — soit le port, soit un nom (Host HTTP ou SNI TLS). Voici l'arbre de décision, le comparatif et le catalogue complet.

📇 Catalogue de cas réels

La commande se lance depuis une machine ayant accès au service (le même réseau local). localhost = remplacez par l'hôte/IP interne si le service tourne ailleurs.

7Tunnels persistants

Gardez un service exposé en continu, avec reconnexion automatique — idéal pour la production.

# autossh : relance le tunnel en cas de coupure réseau
autossh -M 0 -4 -p 443 -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -N -R monapp:80:localhost:3000 localvhost.com

# service systemd — /etc/systemd/system/tunnel.service
[Service]
ExecStart=/usr/bin/ssh -4 -p 443 -o ServerAliveInterval=30 -o ExitOnForwardFailure=yes -N -R monapp:80:localhost:3000 localvhost.com
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target

8Options SSH avancées

Arrière-plan, keep-alive, clé dédiée — identique sous Linux, macOS et Windows.

# arrière-plan (sans shell) + keep-alive
ssh -4 -fN -p 443 -o ServerAliveInterval=30 -R 80:localhost:3000 localvhost.com

# clé SSH spécifique
ssh -4 -p 443 -i ~/.ssh/ma_cle -R 80:localhost:3000 localvhost.com

# Windows (OpenSSH intégré, PowerShell) — même commande
ssh -4 -p 443 -R 80:localhost:3000 localvhost.com

9Exemples par framework

Démarrez votre app en arrière-plan (&), puis ouvrez le tunnel vers son port.

# React / Vue / Angular (dev server :3000)
npm run dev &
ssh -4 -p 443 -R 80:localhost:3000 localvhost.com

# API Node / Express (:8080) avec sous-domaine 'monapi' ('api' seul est réservé)
node server.js &
ssh -4 -p 443 -R monapi:80:localhost:8080 localvhost.com

# Python / Flask (:5000)
flask run --port 5000 &
ssh -4 -p 443 -R 80:localhost:5000 localvhost.com

10Dashboard & analytics temps réel

Chaque tunnel dispose d'un tableau de bord live : trafic en direct (WebSocket), carte des visiteurs géolocalisés, journaux de requêtes, statistiques par pays, par chemin et par navigateur.

# votre dashboard personnel
https://localvhost.com/dashboard

11Sécurité & SSO — Fournisseur d'identité OIDC

LocalVhost embarque un fournisseur OpenID Connect complet (signature RS256, sans dépendance externe). Un seul déploiement authentifie tous vos services auto-hébergés — NetBird (VPN mesh), Grafana, headscale, Proxmox, Portainer… — via Authorization Code + PKCE ou Device Flow, avec sessions longues (refresh token roté), déconnexion SSO et révocation inclus.

Configuration par découverte automatique : pointez chaque service sur l'URL de discovery, il résout seul les endpoints et les clés.

# Découverte OIDC (issuer, endpoints, clés)
https://localvhost.com/.well-known/openid-configuration

Scopes openid profile email offline_access  ·  Claims sub auth_time at_hash preferred_username name email email_verified groups

AuthIssuer: https://localvhost.com
AuthAudience: netbird
AuthKeysLocation:
  …/oidc/jwks.json
OIDCConfigEndpoint:
  …/.well-known/openid-configuration

auth_url  = …/oidc/authorize
token_url = …/oidc/token
api_url   = …/oidc/userinfo
scopes = openid profile email offline_access
use_pkce = true
use_refresh_token = true
role_attribute_path =
 contains(groups[*],'admins')
   && 'Admin' || 'Viewer'

issuer: https://localvhost.com
client_id: headscale
client_secret: <secret>
scope:
  [openid, profile, email]
allowed_groups: [users]

Déclarez vos propres services (client_id, secret, redirections) sans recompiler, et pilotez les groupes RBAC par utilisateur :

# Ajouter des clients OIDC (Grafana, headscale, …)
OIDC_EXTRA_CLIENTS='[{"id":"grafana","secret":"CHANGEME",
  "name":"Grafana","redirect_uris":["https://grafana.exemple.com/login/generic_oauth"],
  "post_logout_redirect_uris":["https://grafana.exemple.com/login"]}]'
# Groupes du claim "groups" par utilisateur (RBAC)
OIDC_GROUPS_JSON='{"admins":["alice"],"ops":["bob","carol"]}'