Problématique

Le protocole SSH permet la connexion à des serveurs Unix/Linux distants au travers d’un réseau TCP/IP. Sa couche de chiffrement permet des connexions sécurisées et rend ssh nettement plus sécurisé que ses ancêtres telnet ou rlogin, c’est pourquoi il est universellement utilisé aujourd’hui.

Considérons le cas typique suivant où la machine alpha ouvre une session vers la machine beta :

	
 alpha -------------> beta 
10.0.0.11          10.0.0.12

Les échanges de clés ont été réalisés pour des connexions sans mot de passe entre les serveurs. Cependant, aucune résolution DNS n’est disponible sur la maquette, on est donc initialement limité à la connexion via l’adresse IP :

[root@alpha ~]# ssh 10.0.0.12
Last login: Mon Mar 25 16:14:26 2019 from alpha.local
[root@beta ~]#

Parfois, la machine à laquelle on accède n’est pas le serveur final sur lequel on souhaite travailler. Il peut s’agir d’un serveur de rebond qui permet la connexion à des partenaires et qui leur donne l’accès à certains serveurs internes. Ici, on souhaite se connecter au serveur gamma.

Au niveau configuration réseau, le serveur intermédiaire a deux interfaces sur des réseaux logiques différents. L’une permet l’accès à alpha, l’autre à gamma. Le serveur beta ne route pas ces deux réseaux, ce qui empêche la connectivité IP entre alpha et gamma.

alpha -------------> beta ----------> gamma
10.0.0.11   10.0.0.12 <> 10.1.0.1    10.1.0.2

L’usager connecté à la machine alpha ne pouvant pas directement contacter gamma en TCP/IP, il ne peut pas établir la connexion ssh vers ce serveur. Pour y accéder, il se connecte en premier lieu à beta qui, lui, peut établir la connexion vers gamma.

[root@alpha ~]# ssh 10.0.0.12
Last login: Mon Mar 25 16:43:57 2019 from 10.0.0.11
[root@beta ~]# ssh 10.1.0.2
Last login: Mon Mar 25 16:44:02 2019 from 10.1.0.1
[root@gamma ~]#

On doit donc effectuer manuellement ce rebond supplémentaire pour se connecter au serveur cible. Cela peut convenir pour l’ouverture de sessions interactives ponctuelles, mais cette solution présente un inconvénient majeur lorsque l’on souhaite copier des fichiers entre alpha et gamma via scp. En effet, avec cette méthode, on est dans l’obligation de copier les fichiers sur beta avant de pouvoir les rapatrier sur alpha, on doit donc faire deux scp pour arriver à nos fins.

Solution

Le client SSH propose une solution pour pallier ce problème, il s’agit des directives ProxyCommand du fichier de configuration du client ssh.

Considérons la configuration suivante dans le fichier ~/.ssh/config du serveur alpha (à créer si inexistant) :

	
# Ce bloc décrit le serveur beta auquel nous avons directement accès. Cette entrée seule permet de faire "ssh beta" pour se connecter au serveur à l'adresse 10.0.0.12, et ce sans résolution DNS.
Host beta
User root
Hostname 10.0.0.12

# Ce bloc décrit le serveur cible gamma avec son adresse IP. Le serveur intermédiaire beta est spécifié dans la directive ProxyCommand, et la connexion est prolongée jusqu'au serveur cible.
Host gamma
Hostname 10.1.0.2
User root
ForwardAgent yes
ProxyCommand ssh beta -W %h:22

Après sauvegarde de cette configuration, on constate que ssh est capable de rendre transparent le rebond. A savoir qu’il est possible depuis le serveur alpha de faire simplement :

[root@alpha ~]# ssh gamma
Last login: Mon Mar 25 16:20:37 2019 from 10.1.0.1
[root@gamma ~]#

Envoyer un fichier vers gamma via scp se fait également de manière transparente :

[root@alpha ~]# echo "Hello World" > test_file
[root@alpha ~]# scp test_file gamma:/tmp
test_file                                     100%   12     8.6KB/s   00:00
[root@alpha ~]# 

Le cas de cet exemple est très basique, mais on peut cascader les rebonds indéfiniment. Plus le nombre de rebond est grand, plus leur automatisation sera bénéfique. On pourrait imaginer rajouter une nouvelle ProxyCommand basée sur le serveur gamma pour accéder à un serveur delta (accessible seulement depuis gamma) sur un réseau IP encore différent 10.2.0.0.

alpha -------------> beta ----------------> gamma ----------> delta
10.0.0.11   10.0.0.12 <> 10.1.0.1   10.1.0.2 <> 10.2.0.1     10.2.0.2

Voici la configuration complète permettant d’accéder à tous les serveurs :

# Ce bloc décrit le serveur beta auquel nous avons directement accès. Cette entrée seule permet de faire "ssh beta" pour se connecter au serveur à l'adresse 10.0.0.12, et ce sans résolution DNS.
Host beta
User root
Hostname 10.0.0.12

# Ce bloc décrit le serveur cible gamma avec son adresse IP. Le serveur intermédiaire beta est spécifié dans la directive ProxyCommand.
Host gamma
Hostname 10.1.0.2
User root
ForwardAgent yes
ProxyCommand ssh beta -W %h:22

# Ce bloc décrit le serveur cible delta avec son adresse IP. Le serveur intermédiaire gamma est spécifié dans la directive ProxyCommand.
Host delta
Hostname 10.2.0.2
User root
ForwardAgent yes
ProxyCommand ssh gamma -W %h:22

Au delà du gain de temps à pouvoir ouvrir une session interactive directe sur un serveur joignable uniquement par de multiples rebonds, on gagnera beaucoup de temps lorsque l’on souhaite télécharger des fichiers depuis ou vers le serveur distant. En effet, la commande scp va fonctionner de manière transparente vers ce dernier, comme si ce serveur était directement joignable.