Sshuttle : le tunnel magique et sécurisé

I. Présentation

Qui n’a pas été confronté à l’épineux problème des pare-feu de sécurité qu’il faut traverser en passant toute sorte de protocoles ? Et bien sachez qu’il existe une solution très simple à mi-chemin entre le VPN et le tunnel SOCKS. Cet outil merveilleux s’appelle sshuttle. Ce logiciel permet d’utiliser une connexion sécurisée SSH en tant que simple utilisateur (c’est-à-dire non connectée en tant que root), mais comme un tunnel VPN transparent.

Cela fonctionne aussi bien sur des systèmes d’exploitation Microsoft Windows, Linux/Unix voire même MacOS. Comme on vient de le mentionner le principe se trouve à la frontière entre un tunnel VPN et la redirection de port (que l’on connaît aussi sous l’appellation port forwarding), permettant de faire transiter sa connexion réseau au travers de n’importe quel serveur SSH, auquel on peut accéder grâce à sshuttle.

II. Les prérequis

Avant toute chose, pour pouvoir fonctionner correctement l’utilitaire sshuttle nécessite tout de même un certain nombre de prérequis :

• un accès root à la machine cliente (celle à connecter au pseudo-VPN).
• un pare-feu local sur la machine cliente : firewalld (ou anciennement iptables).
• la suite logicielle python la plus récente possible.

Sur le principe, on va faire passer des flux multiples au sein d’un même canal sécurisé par SSH. Personnellement j’ai eu à l’utiliser pour mettre en relation deux proxy servers : l’un devant permettre l’installation d’une suite logicielle et d’un Framework sur le second.

REMARQUE : on peut aussi imaginer toute sorte de situation, comme le transfert de messages SMTP ou de trafic Web http au travers de ce tunnel SSH.

Un point essentiel pour pouvoir faire fonctionner cela, en passant par un utilisateur autre que root c’est qu’il faut configurer le client SSH de l’utilisateur en question. Je prendrai ici comme exemple un utilisateur phil pour lequel je dois en premier lieu créer une paire de clé privée/publique :

$ ssh-keygen –b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/phil/.ssh/id_rsa) :
Your identification has been saved in /home/phil/.ssh/id_rsa.
Your public key has been saved in /home/phil/.ssh/id_rsa.pub.
…

On dispose désormais, dans le répertoire /home/phil/.ssh des deux fichiers de clés publique/privée :

• id_rsa.pub
• id_rsa

Ensuite, on doit également créer un fichier config dans lequel on va positionner l’ensemble de nos options, y compris le proxy mandataire que l’on doit utiliser pour mettre en œuvre le trafic sécurisé, au travers du tunnel SSH :

$ cd /home/phil/.ssh
$ vi config

REMARQUE : en effet, il est possible de "proxyfier" des flux web de type HTTP ou HTTPS (via les variables http_proxy et https_proxy à positionner dans le fichier bashrc), ou encore des téléchargements via wget (au travers du fichier wgetrc). Mais, il est très difficile de faire cela pour un client SSH. C’est pourquoi on a recours, ici au programme connect.

Ce fichier doit alors contenir l’ensemble des directives permettant d’établir la connexion polyvalente sécurisée décrite par le schéma ci-dessus. On devrait donc déclarer les instructions suivantes (pour une machine distante à l’adresse IP 50.110.152.48 en passant par le proxy 10.210.43.43 sur le port 8080:

 Host 50.110.152.48
 User phil
 Hostname remote-proxy.mydmn.org
 ProxyCommand connect -H 10.210.43.43:8080 %h 22
 LocalForward 8080 remote-proxy.mydmn.org:80
 IdentityFile ~/.ssh/id_rsa

REMARQUE : le programme connect.c se télécharge facilement sur Internet et se compile de la façon suivante :

# gcc connect.c –o connect

ATTENTION : lorsque le tunnel sera établit tous les flux passeront dedans, à l’exception de ce qui touche aux protocoles ICMP et UDP. Mais, cela suffit à établir un trafic sécurisé au travers d’un serveur de confiance, même lorsque l’on utilise une borne WiFi publique.

II. L’installation de sshuttle

L’installation de l’utilitaire sshuttle peut se faire directement au travers de l’installation du package pip (gestionnaire d’application Python), sur la plupart des distributions Linux :

# easy_install pip
# pip install sshuttle

On peut aussi utiliser le dépôt GitHub pour cloner l’environnement du projet en local sur son propre serveur :

# git clone https://github.com/sshuttle/sshutle.git
# cd sshuttle ; ./setup.py install

Sur les distributions de type CentOS/RedHat, il suffit d’installer le dépôt EPEL pour ensuite atteindre le package sshuttle :

# rpm –Uvh epel-release*.rpm
# yum install sshuttle

Pour finir mentionnons que sur des distributions Debian/Ubuntu, il faut installer les packages suivants, puisque iptables n’est pas systématiquement activé :

$ sudo apt-get update
$ sudo apt-get install sshuttle iptables

III. L’utilisation de sshuttle

La syntaxe générale de cette commande est la suivante :

$ ./sshuttle –r <User>@<SSH Server> 0.0.0.0/0 -vvv

L’option –vvv n’est pas obligatoire, mais permet d’introduire un niveau de verbosité important, en affichant tout les flux et les échanges effectués au sein du tunnel. On peut alléger ce niveau de verbosité en ne mettant que –v (ou en omettant carrément la verbosité).

ASTUCE : si l’on souhaite que le trafic DNS passe également par le tunnel sécurisé, il faut alors ajouter l’option –D (ou --dns). La commande demande alors à la fois le mot de passe du compte local et celui du serveur distant, en résolvant les noms DNS.

Il est possible d’exclure les flux de certaines adresses (ou machines) en utilisant l’option –x :

$ ./sshuttle –r phil@<Server>.mydmn.org -x XXX.YYY.ZZZ.0/24 0/0

Cela exclut alors les machines XXX.YYY.ZZZ.1 à XXX.YYY.ZZZ.254 de l’utilisation du tunnel. Si l’on souhaite n’exclure qu’une et une seule machine, il suffit de préciser son adresse IP : -x 192.168.1.253. Pour éviter d’avoir à définir les sous-réseaux à utiliser, on peut laisser sshuttle les sélectionner pour nous, grâce à l’option -N :

$ ./sshuttle –rN phil@<Server>.mydmn.org

De plus, on peut également demander à l’outil de mettre en place les associations adresse IP/Host directement dans le fichier /etc/hosts du serveur local, via l’option –H. D’après l’exemple vu précédemment, on devra alors exécuter dans une première session la commande suivante :

$ sshuttle --dns –vvv –e "ssh –i /root/.ssh/id_rsa" –r [email protected] 0/0

A partir de là, le pare-feu local sera activé, sous forme de règles iptables et bloquera tout ce qui ne fait pas partie du tunnel sécurisé. On ne pourra donc plus exécuter de commandes locales. C’est pourquoi, il est préférable d’ouvrir une seconde fenêtre avant d’exécuter la commande sshuttle, afin de pouvoir lancer les commandes devant être exécutées sur le serveur distant, au travers du proxy SSH.

IV. Conclusion

Ainsi, il devient facile d’établir des connexions avec n’importe quel serveur distant, même au travers d’une architecture sécurisée complexe traversant différents pare-feu ou proxy mandataire. Pour ma part, je l’ai utilisé pour pouvoir effectuer une installation distante d’une suite logicielle localisée dans le Cloud sur Amazon, en traversant mon propre proxy (10.210.43.43 sur le port 8080), et celui de l’éditeur. Mais, de nombreuses autres “use case“ peuvent être appliqués sur des protocoles aussi divers que HTTP, FTP, SMTP, SSH, etc.

Philippe PIERRE

A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.

See Full Bio