Comme nous allons le voir, SSH est bien plus qu'un shell distant. C'est aussi un outil qui permet très aisément de creuser différents types de tunnel. Comprendre l'architecture logicielle de SSH et comprendre comment il permet de créer des tunnels nous permettra d'aborder plus facilement n'importe quel outil de tunneling. Aussi SSH sera beaucoup cité dans les exemples mis en oeuvre dans les parties suivantes.

L'outil SSH                                                                                               

SSH (Secure Shell v2) est un protocole de niveau applicatif :

Ce protocole est définit par un ensemble de RFC [4250 - 4255]

• 4251 - "The SSH Protocol Architecture"
• 4252 - "The SSH Authentication Architecture"
• 4253 - "The SSH Transport Architecture"
• 4254 - "The SSH Connection Architecture"

C'est essentiellement la RFC 4254 qui va nous intéresser, à savoir la RFC qui décrit comment SSH permet la création de tunnels.

L'archtiecture logicielle de SSH - Les 3 protocoles internes                    

SSH est organisé de 3 protocoles, chacun de ces protocoles répondant aux spécifications des RFC citées précédemment:

Nous allons aborder rapidement les protocoles d'authentification et de transport, ces derniers ayant déjà étudiés en cours. Aussi on portera une attention particulière au protocole de connection.

L'archtiecture logicielle de SSH - SSH Transport Layer Protocol              

Comme vu en cours, le TLP de SSH est responsable de l'établissement d'une connexion chifrée et de l'authentification du serveur. Les principaux mécanismes utilisés ici sont l'échange de clef de session via Diffie Hellman et l'authentification du serveur, qui a lieu penant l'échange Diffie Hellman. Le schéma suivant récapitule l'ensemble de ces différentes étapes:

L'archtiecture logicielle de SSH - SSH Authentication Layer Protocol      

SSH met à disposition plusieurs méthodes pour authentifier le client. Il faut noter que ce protocole d'authentification du client est encapsulé dans le TLP, de ce fait toutes actions mises en oeuvre dans le protocole d'authentification du client sont censées être chifrées et sûres. Ces méthodes sont décrites dans la RFC 4252.

les différentes méthodes sont :

• PublicKey => Le client dispose d'une clef publique et le serveur a confiance en cette clef.
• Password => La plus connue et la plus usitée, le client envoie son mot de passe.
• HostBased => Le même principe que PublicKey mais c'est un "host" qui est authentifié. L'idée est qu'il peut y avoir plusieurs clients provenant d'un même host.

Typiquement, lors de l'utilisation de ce protocole, le client enverra un message formaté comme suit:

L'archtiecture logicielle de SSH - SSH Connection Layer Protocol            

C'est ce protocole qui est utilisé lors de l'établissement d'un shell distant. C'est aussi ce protocole que nous utiliserons lorsque nous aurons besoin de créer des tunnels. A noter qu'ici aussi, ce protocole fonctionne au dessus de TLP et se retrouve donc implicitement chiffré.

Nous ne détaillerons pas l'établissement d'un shell mais bien la création de deux différents types de tunnels, à savoir :

• Le local port forwarding
• Le remote port fowarding

Local Port Fowarding

Le client C initie une connexion SSH vers le serveur SSH S. En plus de la connexion active vers le serveur SSH, le client écoute en plus sur un port X d'une interface Y. L'idée est que lorsque qu'une connexion est initiée vers Y:X du client alors ce dernier envoie le message suivant au serveur :

Ce message permet au client de signaler au serveur qu'il doit forwarder ce flux (relatif à un canal de données SSH) vers l'adresse "host to connect" sur le port "port to connect". Nous avons crée un tunnel applicatif!

La commande typique permettant de faire un tunnel de la sorte est la suivante :

ssh -L localhost:7777:bulbizzare:80 IPserveurSSH

Nous obtenons le schéma logique suivant :

Retour au modèle OSI, nous avons bien un tunnel applicatif (ici HTTP)/ applciatif (SSH) :

Voyons maintenant un autre type de tunnel que SSH met à notre disposition.

Remote Port Fowarding

Dans ce scénario le client C initie une connexion SSH vers le serveur SSH S. Pour avertir le serveur de possibles connexions "reverse", le client envoie alors un message formaté comme suit:

En plus de sa connexion SSH, le serveur SSH écoutera alors sur son interface X et sur le port Y. Lorsqu'une connexion sera initiée sur X:Y du serveur, ce dernier enverra au client un message formaté comme suit :

Si le client accepte (normalement c'est le cas..), un canal sera alors ouvert et dédié au tranfert de ce flux, du serveur vers le client.

Bob étant le client, Bulbizzare étant le serveur SSH, la commande typique permettant de faire un tunnel de la sorte est la suivante :

ssh -R ipbulbizzare:7777:ipSalameche:21 IPBulbizzare

Nous obtenons le schéma logique suivant :

Lorsque Alice initiera une connexion sur le port 7777 de l'interface publique de bulbizzare, le trafic sera alors redirigé vers Bob et ce dernier l'enverra vers le serveur FTP salamèche. Cet exemple n'est pas forcément pertinent (ni sécurisé) mais permet de comprendre facilement le cas de "reverse tunneling".

Ce qu'il faut retenir                                                                                 

SSH est un outil puissant pour faire du tunneling. Il permet :

• Le local port forwarding
• Le remote port fowarding
• Une connexion chiffrée et authentifiée