Bonjour ! Êtes-vous intéressé par le monde de l'accès à distance via SSH ? Dans mes précédents articles, j'ai abordé la génération de clés SSH, les commandes de base d'accès et le transfert de port local (-L). Aujourd'hui, nous allons nous concentrer sur une autre fonctionnalité puissante de SSH : le transfert de port inverse (Reverse Port Forwarding), c'est-à-dire l'option -R.

Si l'option -L permet "d'ouvrir un tunnel de mon ordinateur vers l'extérieur pour accéder aux ressources externes", l'option -R fait le contraire. Elle permet de "creuser un tunnel de l'ordinateur externe vers mon ordinateur pour accéder aux ressources internes", comme si l'on fabriquait une porte dans un mur.

Qu'est-ce que le transfert de port inverse ? (aperçu de l'option -R)

En général, il est difficile de se connecter directement depuis un serveur distant (Serveur A) à un ordinateur local (Client B). La plupart du temps, c'est parce que le Client B utilise une adresse IP privée, est derrière un pare-feu, ou n'a pas d'IP fixe.

Dans ce cas, en utilisant le transfert de port inverse (-R), le Client B peut essayer de se connecter à Server A via SSH tout en demandant à Server A d'ouvrir un tunnel et de rediriger les requêtes entrantes vers un port spécifique de Client B.

En d'autres termes :

  1. Client B (mon ordinateur) tente de se connecter à Server A (serveur externe) via SSH.
  2. À ce moment, en utilisant l'option -R, il donne l'instruction : "Envoie les requêtes entrantes du port X de Server A vers le port Y de mon ordinateur (Client B) !".
  3. Désormais, lorsque d'autres utilisateurs externes se connectent au port X de Server A, cette demande est redirigée vers le port Y de Client B via le tunnel SSH.

C'est comme si le Client B demandait à Server A de "créer une porte pour se connecter à moi".

Diagramme de transfert de port inverse SSH : structure de la transmission des requêtes externes vers le local via le serveur

-R format de la commande

Le format de base de la commande pour le transfert de port inverse est le suivant :

ssh -R [port_distant]:[hôte_cible]:[port_cible] [utilisateur_serveur_distant]@[adresse_serveur_distant]

Examinons chaque élément en détail :

  • ssh : commande pour exécuter le client SSH.
  • -R : option pour le transfert de port inverse.
  • [port_distant] : numéro de port du serveur distant (Serveur A) où le tunnel sera ouvert. Si un utilisateur externe se connecte à ce port, il se connectera aux ressources de Client B.
  • [hôte_cible] : Nom d'hôte ou adresse IP de la ressource à laquelle [utilisateur_serveur_distant]@[adresse_serveur_distant] se connecte, au sein de Client B (mon ordinateur). Cela sera généralement localhost (c'est-à-dire Client B lui-même).
  • [port_cible] : numéro de port d'un service ouvert sur Client B (mon ordinateur). C'est là où les requêtes provenant de l'extérieur arriveront finalement.
  • [utilisateur_serveur_distant]@[adresse_serveur_distant] : compte utilisateur et adresse du serveur distant (Serveur A) pour établir le tunnel. C'est le chemin que Client B utilise pour se connecter à Server A.

Exemple :

Pour se connecter au port 8888 du serveur externe (Serveur A) de mon serveur web local (Client B) sur le port 8080 :

# Exécuté sur Client B (mon ordinateur)
ssh -R 8888:localhost:8080 user@server_a_public_ip

Lorsque cette commande est exécutée avec succès, vous êtes connecté à server_a_public_ip via SSH. À ce moment, si un autre ordinateur se connecte à http://server_a_public_ip:8888, il accédera en réalité au port 8080 de Client B (mon ordinateur).

Quand le transfert de port inverse est-il utile ? (Utilisation en développement)

Le transfert de port inverse est extrêmement puissant dans des situations spécifiques où la simple connexion SSH ne suffit pas. Il peut être particulièrement utile pendant le développement.

1. Rendre un serveur de développement local derrière un NAT/pare-feu public

  • Problème : Vous avez une application web en cours de développement sur votre réseau domestique ou interne (par exemple, exécutée sur localhost:3000). Vous voudriez montrer cette application à des collègues ou clients externes, mais votre ordinateur local utilise une IP privée et ne peut donc pas être atteint directement depuis l'extérieur. La configuration de votre routeur ou du pare-feu de l'entreprise peut être compliquée et nécessiter une approbation de l'administrateur.
  • Solution : Vous pouvez exposer votre serveur de développement local sur un serveur externe avec une IP publique (par exemple, une instance AWS EC2, un VPS).
# Exécuté sur ma machine de développement locale (Client B)
ssh -R 80:localhost:3000 your_user@your_public_server.com
# Ou pour éviter d'utiliser le port 80 qui nécessite des droits root, utiliser un autre port (ex. : 8080)
ssh -R 8080:localhost:3000 your_user@your_public_server.com

Ensuite, en accédant à `your_public_server.com:8080`, vous atteindrez réellement l'application web en cours d'exécution sur votre machine locale (`localhost:3000`). Vous pouvez désormais suivre votre progression de développement en temps réel.

2. Tester des webhooks

  • Problème : Vous souhaitez tester des événements de webhook provenant de systèmes de paiement, de dépôts Git (GitHub/GitLab), de plateformes de messagerie, etc., sur votre serveur de développement local. Toutefois, les webhooks ne peuvent être envoyés que vers des URL publiques.
  • Solution : À l'aide du transfert de port inverse, vous pouvez mapper le point de terminaison de webhook local (par ex. : localhost:5000/webhook) vers une URL spécifique de votre serveur public.
# Exécuté sur ma machine de développement locale (Client B)
ssh -R 5000:localhost:5000 your_user@your_public_server.com

Désormais, en saisissant `http://your_public_server.com:5000/webhook` dans la configuration de votre webhook, les événements de webhook seront transmis à votre serveur local pour que vous puissiez les tester.

3. Accès direct à un port spécifique sur un serveur distant (contournement de réseau sécurisé)

  • Problème : Vous souhaitez accéder directement à une base de données ou un outil de gestion installé sur un serveur à distance (Client B) qui est accessible sur un port spécifique (par exemple, localhost:9000), mais le serveur est bloqué par un pare-feu ou est sur un réseau privé. Cependant, Client B peut accéder à un serveur public (Serveur A) via SSH.
  • Solution : En connectant Client B à Server A via SSH et en demandant le transfert de port inverse, Client B demande à Server A "Crée un chemin vers mon port 9000".
# Exécuté sur Client B (serveur derrière un pare-feu)
ssh -R 9000:localhost:9000 your_user@server_a_public_ip

Désormais, en accédant à `server_a_public_ip:9000` depuis votre ordinateur (ou tout autre ordinateur externe), vous pourrez accéder au service sur le port 9000 de Client B.

4. Démonstration temporaire ou partage

  • Problème : Vous souhaitez montrer à un collègue le fonctionnement d'une application en cours d'exécution sur votre machine locale, ou partager temporairement pour obtenir des retours.
  • Solution : Vous pouvez exposer temporairement un service local à l'extérieur via un simple transfert de port inverse. Une fois la démonstration terminée, vous pouvez facilement fermer la session SSH pour bloquer l'accès.

Considérations lors de l'utilisation du transfert de port inverse

  • GatewayPorts yes : les ports distants ouverts par le transfert de port inverse sont, par défaut, accessibles uniquement depuis la machine où le serveur SSH (server_a_public_ip) tourne. Si d'autres ordinateurs en dehors du serveur SSH doivent pouvoir accéder à ce port, vous devez ajouter la configuration GatewayPorts yes dans le fichier sshd_config du serveur SSH et redémarrer le service SSH. (Cette configuration peut avoir des implications sur la sécurité, soyez vigilant.)

  • Sécurité : Le transfert de port inverse expose un port spécifique de votre réseau local vers l'extérieur, donc il doit être utilisé uniquement sur des serveurs de confiance. Vous devez préalablement vérifier les vulnérabilités de sécurité du service exposé.

  • Maintien de la session SSH : Le tunnel de transfert de port inverse n'est valide que tant que la session SSH est maintenue. Pour qu'il s'exécute en arrière-plan, il est courant d'utiliser les options ssh -fN -R ... avec f (exécution en arrière-plan) et N (ne pas exécuter de commande distante).

Conclusion

Le transfert de port inverse SSH (-R) est une fonctionnalité très utile lorsque vous devez exposer un service spécifique dans des environnements réseau complexes ou derrière des pare-feux. Il peut être un outil de productivité puissant, surtout après avoir partagé un environnement local ou testé des webhooks.

Si cela semble être un concept difficile à comprendre, la meilleure façon d'apprendre est de l'essayer réellement. Commencez à utiliser le transfert de port inverse SSH dans votre flux de travail de développement !

Si vous avez des questions, n'hésitez pas à les poser dans les commentaires !