Le WordPress d'aujourd'hui, décodé pour les développeurs

Outils & workflow

Un tunnel SSH initié depuis le serveur pour dépanner sans accès entrant

Quand aucun accès entrant n'est ouvert sur le réseau d'un client, une connexion initiée depuis le serveur lui-même permet une intervention ponctuelle sans configuration réseau permanente.

Par WordPress Développement • 16 juin 2022 • 4 min de lecture • Aucun commentaire
Un tunnel SSH initié depuis le serveur pour dépanner sans accès entrant

ssh -R 2222:localhost:22 intervenant@serveur-relais.exemple : cette commande, exécutée directement depuis un serveur situé derrière un pare-feu strict sans aucun port entrant ouvert, établit une connexion sortante vers un serveur relais accessible publiquement, tout en ouvrant sur ce relais un port qui redirige vers le port SSH du serveur d’origine. Le développeur peut alors se connecter au serveur relais et, de là, atteindre le serveur initialement injoignable, sans qu’aucune configuration réseau permanente n’ait été modifiée chez le client.

Le contexte : aucun accès entrant possible sur le réseau du client

Certains environnements clients n’autorisent aucune ouverture de port entrant, pour des raisons de politique de sécurité interne strictement appliquées par leur propre service informatique. Un dépannage ponctuel devient alors délicat : le développeur ne peut pas initier une connexion vers le serveur, puisque aucun port entrant n’est accessible depuis l’extérieur de ce réseau.

Le principe du tunnel inversé

L'essentiel à retenir : Un tunnel SSH inversé s'initie depuis le serveur à dépanner, pas depuis le poste du développeur ; Aucune ouverture de port entrant permanente n'est nécessaire sur le réseau du client ; La connexion se referme d'elle-même une fois l'intervention terminée

Un tunnel SSH classique est initié par la personne qui souhaite se connecter, vers la machine cible. Le tunnel inversé fonctionne à l’opposé : c’est le serveur à dépanner, situé derrière le pare-feu, qui initie lui-même une connexion sortante vers un serveur relais disposant d’une adresse publique accessible. Cette connexion sortante n’est généralement pas bloquée par les politiques de sécurité, qui restreignent le plus souvent les connexions entrantes bien plus que les connexions sortantes.

# Depuis le serveur à dépanner, derrière le pare-feu client :
ssh -R 2222:localhost:22 intervenant@serveur-relais.exemple -N

# Depuis le poste du développeur, une fois le tunnel établi :
ssh -p 2222 utilisateur@serveur-relais.exemple

La première commande maintient une connexion ouverte depuis le serveur client vers le relais, sans exécuter de commande distante grâce à l’option -N, uniquement pour transporter le tunnel. La seconde commande, exécutée par le développeur depuis son propre poste, se connecte au relais sur le port redirigé, et atteint ainsi le serveur du client comme s’il s’y connectait directement.

Ce que cette méthode demande comme préparation

  • Un serveur relais accessible publiquement, sous le contrôle de l’agence, doit exister au préalable.
  • Le serveur à dépanner doit disposer d’un accès sortant SSH vers ce relais, ce qui reste très généralement autorisé.
  • Une clé SSH dédiée à cet usage ponctuel limite les risques en cas d’oubli de fermeture du tunnel.

Une utilisation ponctuelle, pas une solution permanente

Ce mécanisme convient à une intervention ponctuelle et encadrée, pas à un accès permanent laissé ouvert sans surveillance. Une fois l’intervention terminée, la connexion établie par la commande ssh -R doit être fermée explicitement, ce qui referme immédiatement le tunnel et empêche tout accès ultérieur au serveur du client par ce biais.

# Fermer proprement le tunnel une fois l'intervention terminée
# (interrompre le processus ssh -R lancé sur le serveur client)
kill %1

Un accès temporaire, ouvert consciemment et refermé tout aussi consciemment, vaut mieux qu’un port entrant permanent qu’on finit par oublier.

Une communication claire avec le client reste indispensable

Cette méthode ne dispense jamais d’informer clairement le client de l’intervention en cours et de sa durée, y compris lorsque le mécanisme technique ne nécessite aucune action de sa part. La transparence sur ce type d’accès temporaire fait partie intégrante d’une relation de confiance durable avec un client dont l’infrastructure reste sous sa responsabilité.

Rendre la connexion plus robuste face aux coupures réseau

Sur une connexion réseau instable, un tunnel inversé maintenu manuellement peut se rompre sans avertissement, interrompant l’intervention en cours. L’outil autossh surveille la connexion établie et la relance automatiquement en cas de coupure, ce qui évite de devoir relancer manuellement la commande depuis le serveur du client à chaque micro-coupure du réseau.

autossh -M 0 -R 2222:localhost:22 intervenant@serveur-relais.exemple -N

Cette robustesse supplémentaire reste utile essentiellement pour des interventions prolongées ; pour un dépannage de quelques minutes, la commande ssh -R directe reste largement suffisante et plus simple à mettre en œuvre dans l’urgence.

En résumé

Face à un réseau client qui n’autorise aucun accès entrant, un tunnel SSH inversé initié depuis le serveur lui-même permet un dépannage ponctuel sans modification permanente de la configuration réseau. Cette méthode reste réservée à des interventions encadrées, refermées explicitement une fois le dépannage terminé.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi