Le multiplexage sous Openssh. Pourquoi ? Comment ?

Par Rédaction, secuobs.com
Le 12/01/2006

---

Résumé : Ce tutoriel est idéal pour ceux qui ont besoin d'ouvrir régulièrement et rapidement de nombreuses sessions clientes SSH tout en faisant gagner des ressources à leur système sans toutefois désirer passer par une authentification par clés publiques. - Lire l'article



Ce tutoriel est idéal pour ceux qui ont besoin d'ouvrir régulièrement et rapidement de nombreuses sessions clientes SSH vers une même machine tout en faisant gagner des ressources à leur système sans toutefois désirer passer par une authentification basée sur l'échange de clés publiques.

Il a été réalisé à partir d'une présentation effectuée le 10 janvier 2006 par Saâd Kadhi lors des mini-conférences (une aprés-midi, deux présentations) gratuites et libre d'entrée comme à l'habitude, organisées régulièrement par l'OSSIR (Observatoire de la Sécurité des Systèmes d'Information et des Réseaux ) et son groupe "SUR" spécialisé dans la Sécurité des systèmes Unix & des Réseaux. Cette session était située à l'Ecole d'Enseignement Supérieur des Arts et Métiers (ENSAM).

Le multiplexage a été introduit dans la version 3.9 d'Openssh le 17 août 2004. C'est une fonction nouvelle dans une échelle de temps "informatique" ; encore relativement peu utilisée, elle est stabilisé entre les versions 4.0 & 4.1 pour finalement trouver sa maturité dans la version 4.2.

Le principe est simple, on ouvre une seule requête d'authentification de la machine cliente vers le serveur distant, puis on fait passer l'ensemble des prochaines sessions vers la même machine via cette première connexion qui sert de "pseudo-tunnel".

L'authentification unique permet notamment de gagner du temps en simplifiant les processus ssh via par exemple l'auto-complétion si vous utilisez un shell (invite de commande) comme bash par exemple.

Gain de performance egalement grâce a la réduction du nombre d'établissements de sessions via l'echange de clés publiques, les clés évoluant en compléxité & en longueur avec les différentes époques.

La première session est dite session "maître" et les suivantes sont les sessions "multipléxées" ; elles utilisent la socket (ndlr : ce n'est pas une chaussette mais une norme de communication réseau) ouverte localement par la session "maître" ssh afin d'accéder aux diffénts types de service proposés par le protocole ssh : - les transferts de fichiers avec scp ou sftp ainsi que le X11 Forwarding et l'Agent Forwarding.

Pour se faire, finalement peu de manipulations à effectuer, l'ensemble de la configuration se situant au niveau du client, vous n'aurez en aucun cas à toucher à vos serveurs ssh pour les fichiers de paramêtrage ou pour la mise à jour, toutes les versions étant compatibles. Vous l'aurez compris, une version de Openssh client suffit et cela à partir de la version 3.9, de préférence la 4.2 (cf. plus loin pourquoi avec le mode "opportunistic").

D'un point de vue securite, la session "maître" ouvre une socket locale protégée par le système de fichier via les autorisations d'accès au niveau des utilisateurs. L'établissemet d'une session "maître" implique une notion de session dans le temps d'où une fenetre de visibilité au risque plus importante pour une hypothétique compromission. La sécurité de l'ensemble des sessions multipléxées reposent sur la sécurité de la session "maître" ; si cette dernière est compromise, l'ensemble des sessions en découlant est donc potentiellement compromis également.

Au niveau des contraintes, on notera que le multiplexage n'est possible "que" via sshv2, ce qui n'est pas une mauvaise chose en soit puisque il serait aujourd'hui hasardeux de s'aventurer à établir des conexions sur une version moindre du protocole potentiellement vulnérables à des attaques de type Man In The Middle (MITM) par exemple.

La deuxième "contrainte" est elle plus "réelle" puisque le nombre de sessions multipléxés est limité à 9 sessions par socket locale, session maitre non incluse. Il est cependant rare d'avoir besoin de 9 sessions ssh vers une même machine à l'exception peut être des processus de maintenance des systèmes (scp) automatisés (via la crontab), sinon vous pouvez privilégier l'utilisation d'un programme comme screen ou l'authentification par clés.

Le multiplexage s'effectue en trois étapes distinctes : - configureation du client ssh, établissement de la session "maître" vers le serveur puis initialisation des sessions multiplexées véhiculées par la précèdente.

L'intêret d'utiliser la version 4.2 réside surtout dans l'usage d'un mode appelé "opportunistic" ; il permet de rendre totalement automatique et transparent le multiplexage pour l'utilisateur. Le client ssh se permettant de profiter de l'"opportunité" d'une session déjà établie pour y passer les suivantes par la méthode du multiplexage, la création d'une session "maître" étant de même si aucune n'existe pour la machine visée.

Manipulation sur le client uniquement oblige, vous devez éditer le fichier de configuration du client ssh. Ce fichier nommé ssh_config se situe sous le chemin suivant ~/.ssh/config oû ~ représente un raccourci d'accès vers le répertoire personnel de l'utilisateur sous lequel vous vous êtes authentifié "localement".

Dans ce fichier, vous devez ajouter ou éditer le bloc de paramètres suivant :

Host *
ControlPath ~/.ssh/ctl-%r%h%p
ControlMaster auto

Un peu d'explication, on demande pour tous les serveurs ssh auquel on souhaitera accéder de créer (si il n'en éxiste pas) ou d'utiliser une session "maître" existante et donc une socket locale via le fichier ctl-%r%h%p placé sous ~/.ssh/ où %r est le nom de l'utilisateur distant, %h celui de la machine distante et %p le numéro de port d'écoute du serveur distant, généralement 22 pour ce protocole.

Les fonctions de multiplexage ne deviennent réellement intéressantes pour un utilisateur qu'à partir du moment où vous pouvez les automatiser afin de les rendre transparente à l'utilisation courante.

La directive "host *" s'applique à l'ensemble des machines, vous pouvez néanmoins spécifier un bloc de configuration pour une machine en particulier avec "host www.secuobs.com" où "www.secuobs.com" est le nom de la machine par exemple ; vous utiliserez alors ce même nom dans votre commande ssh afin d'accéder au serveur ssh de "www.secuobs.com" via "ssh www.secuobs.com".

Il est bien sûr impératif que le terme "www.secuobs.com" soit mappé vers l'ip réelle de votre serveur soit via une déclaration de type DNS soit par l'ajout d'une entrée correspondante dans votre fichier "hosts" (path/chemin : /etc/hosts) afin que la connexion s'établisse sous les conditions des paramètres que vous aurez spécifiés dans ce bloc.

Sachez également que si un paramètre est présent dans le bloc "host *" il s'appliquera à l'ensemble des autres blocs que vous aurez défini dans ce fichier de configuration, le bloc "host www.secuobs.com" dans notre exemple.

Première étape, l'adaptation du fichier de configuration, terminée, un café ?

Nous pouvons passer dès à présent à la création de la session "maître" via la commande "ssh www.secuobs.com" pour une session interactive de premier plan ou "ssh -Nnf www.secuobs.com" pour une session placée en arrière plan.

Dans le cas où vous souhaitez uniquement tester le multiplexage ou ne vous en servir que ponctuellement, vous n'éditez alors pas le fichier de configuration (étape précèdente) et vous lancer la commande "ssh -M www.secuobs.com" qui va vous créer votre session "maître".

Dernière manipulation, la création des sessions multiplexées via une simple commande habituelle "ssh www.secuobs.com" au nombre de neuf maximum pour rappel.

En ce qui concerne le monitoring & les opérations courantes :

- si vous désirez lister les sockets locales, vous pouvez le faire avec la commande "ls -l ~/.ssh/ctl-*",

- si vous voulez vérifier un état de session "maître", "ssh -O check www.secuobs.com",

- et si vous souhaitez terminer une session "maître", "ssh -O exit www.secuobs.com", un "killall -9 ssh" étant tout aussi efficace selon le contexte :)

Il en est fini pour le multiplexage, processus au combien pratique avec pour seul bémol qu'il s'opére au relatif détriment de la sécurité ; l'utilisation de sshv2 en fait cependant une pure spéculation pour le moment. L'anticipation est pourtant une clé charnière de toute bonne politique de sécurité au même titre que le bon sens & l'attention.

Pour télécharger Openssh -> lien
Le site de l'OSSIR -> lien

Merci à l'OSSIR pour son accueil & la qualité des présentations qui nous vous le rappelons se déroulent régulièrement sur Paris et ses environs, l'entrée est libre & gratuite. Pour plus d'informations sur les prochaines conférences lien

Vous pouvez également rencontrer tout ce beau monde à la JSSI (Journée de la Sécurité des Systèmes d'Information) que l'OSSIR organise chaque année ; pour l'édition 2006 ça se passera le 22 mai sur le thème de "Sécurité et dépendance aux nouvelles technologies", vaste programme. Consulter l'URL lien ainsi que l'appel à communication sur lien pour avoir plus d'informations à ce propos.