Utiliser un proxy Socks SSH pour git et gitlab

Cet article a été publié il y a 2 ans 11 mois 22 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Il n’est pas rare, pour des plateformes Kubernetes à destination des clients, qu’on déploie aussi un serveur Gitlab pour gérer les sources des packages Helm et autres Dockerfile à l’usage des applications qui seront déployées. Ce serveur voit ses accès filtrés par IP, du coup, avec une IP dynamique (merci Orange), compliqué de gérer en permanence des règles de flux pour y accéder. Il y a heureusement une solution qui demande un peu de taf.

C’est dans le titre, l’idée va être de faire passer les connexions git et gitlab via un proxy Socks, créé par une connexion SSH. Cette connexion doit se faire sur une machine qui remplit deux critères, avoir une ip fixe, et avoir accès au serveur Gitlab. Si on établit la connexion SSH au serveur en question, c’est parfait ! Et cette connexion passe par un rebond au travers du VPN du boulot, rebond connecté au réseau privé du gitlab par un autre VPN. Ouais le réseau c’est chiant, mais c’est souvent comme ça qu’on procède, pas de connexions SSH via réseau public (et pas question de laisser le SSH ouvert à grand vent).

Notez bien que la configuration « proxy » est utilisable même avec un setup de rebond tel que je l’ai déjà présenté par le passé. C’est pas génial ça ?

On commence donc par créer la connexion/proxy. Il s’agit simplement d’ouvrir un port dynamique qui sera automatiquement paramétré en tant que proxy Socks. Avec OpenSSH sous Linux (ou Windows via WSL), c’est super simple :

À partir de là, on peut configurer nos différents clients pour utiliser ce proxy afin de joindre le domaine utilisé pour le gitlab. Si vous voulez ouvrir le port systématiquement, vous pouvez passer par le fichier ~/.ssh/config :

À ajouter aux autres éventuels réglages spécifiques pour cette connexion (user, clé SSH particulière, etc).

Pourquoi pas le localforward ?

J’ai déjà joué au localforward par le passé, par exemple pour le master k3s. Ça fonctionne bien dans ce cas-là, mais pour Gitlab, l’interface web me mixait des liens en 127.0.0.1:9999/groupe/projet/... et des liens en gitlab.domain.tld/groupe/projet/... et ces liens-là tombaient naturellement dans le vide. Pas du tout pratique donc, le proxy permet d’être complètement transparent, et de ne pas avoir à jouer avec son fichier hosts, ce qui n’est déjà pas une sinécure sous Linux, encore moins sous Windows.

D’ailleurs en parlant des windowsiens, pour ceux qui seraient coincés en enfer et qui utiliseraient encore PuTTY, voire MobaXTerm (oui y’a des masochistes), autant j’ai réussi à faire un truc avec PuTTY honteux au point que je ne détaillerai pas ici, autant MobaXTerm m’a résisté, impossible de créer un tunnel sur une machine derrière un rebond. Windows 10 et 2021, préférez WSL, ça fonctionnera très bien. Vous n’êtes pas obligés d’utiliser un navigateur dans WSL pour pouvoir accéder au port en question, c’est pas super ça ?

Git, tellement souple

En ligne de commande, git est particulièrement intéressant pour l’utilisation de proxy Socks. Pour un clone de départ, il suffit de paramétrer la variable ALL_PROXY avant de faire son clone :

Quoi, c’est tout, c’est aussi simple ? Ben oui, par contre, c’est valable que pour la session en cours. Git est heureusement incroyablement intelligent, et vous pouvez configurer ce proxy pour le dépot de manière persistante :

Les prochaines commandes sur le dépôt tenteront d’interagir avec l’upstream via le proxy configuré. Et foireront si vous oubliez d’ouvrir la session SSH évidemment. Nickel.

UPDATE: je suis tombé sur un article dont j’ai perdu le lien qui explique que sur du git récent on peut carrément définir le proxy pour tout un domaine dans la conf globale. Donc dans le ~/.gitconfig, ça ressemble à ça:

Du coup plus besoin de faire ALL_PROXY=... et git config ..., ça le fait automatiquement, y compris pour les nouveaux clones 😉

Gitlab, une affaire de navigateurs

Pour les navigateurs, c’est un poil différent. Pour Firefox, les paramètres sont natifs, ouvrez le menu des préférences et cherchez proxy, vous verrez le bouton qui va bien.

Il suffit de configurer un proxy Socks 5, sans authentification, avec les mêmes paramètres qu’au dessus. Attention, ça implique de passer toutes les connexions de tous les onglets en cours dans le proxy, car le paramètre est global. Pour une gestion plus fine, il faudra une extension permettant plus de contrôles.

Pour les navigateurs basés sur Chromium, c’est plus compliqué. Par défaut, il n’embarque aucun paramètre natif et repose, notamment sous Windows, sur le proxy global déclaré dans les paramètres réseau. Il faut donc obligatoirement une extension pour faire le boulot, j’ai sélectionné Proxy SwitchyOmega qui m’a donné satisfaction.

Elle permet de déclarer plusieurs proxys, de facilement switcher entre les proxys, il y a même un mode dynamique qui permet de switcher entre plusieurs proxys en fonction du domaine (je n’utilise Chromium que pour des besoins ultra ciblés, malgré tout, il arrive de devoir basculer rapidement d’un projet à l’autre). Bref, vous aurez toutes les clés pour accéder comme il faut à l’interface de votre serveur Gitlab sans risque de conflits de liens/domaines.

Pas que pour Gitlab

Ce système de tunnel SSH est exploitable comme alternative aux VPN qu’on nous vend ad nauseam dans les vidéos Youtube. Il m’est arrivé de tester rapidement des accès à une plateforme par ce biais via plusieurs serveurs dans différents réseaux, pour évacuer un problème dépendant du fournisseur d’accès (déjà eu un incident client déclaré mais au final lié à Orange). Par contre, une des promesses des VPN est de pouvoir contourner les géoblocages mis en place par des plateformes de fourniture de contenu par abonnement, mais la plupart des ranges des hébergeurs sont déjà identifiés et bloqués (vécu par un collègue avec un VPS chez OVH au Canada pour tenter d’accéder au catalogue Netflix US).

Dans l’absolu, vous pouvez faire passer tout type de trafic et d’applications, soit de manière native, soit de manière un peu détournée. Entre le début et la fin de l’écriture/mise en forme de cet article, j’ai rajouté tsocks à ma trousse à outils qui me permet de faire passer… des connexions SSH au travers du proxy SOCKS ouvert… par une autre connexion SSH. Oui, c’est assez tordu, et un jour je vous expliquerai peut-être l’immense bêtise qui m’a poussé à devoir procéder de la sorte.