SSH : X11 forwarding

Table des matières

SSH permet d'obtenir bien plus qu'un simple shell distant sécurisé. Entre autre, il permet de déporter, de manière sécurisée bien entendu, l'affichage de toute application graphique, même un bureau complet. Je ne suis pas un fan de l'utilisation d'un serveur X sur une machine ayant un rôle de serveur mais, pourtant, des utilisateurs m'ont récemment demandé la possibilité d'avoir un accès graphique complet à un serveur sous Fedora.

Connexion simple et directe

Par connexion simple et directe, j'entends que le client se connecte directement au serveur, sans serveur SSH intermédiaire.

Voici un schéma pour bien comprendre (source : kuxon.org) :
schema connexion SSH simple et directe

Préparatifs

Si votre client est sous GNU/Linux

Mode X11Trusted ou mode X11Untrusted ?
Pour tout savoir du mode X11 trusted/untrusted, je vous recommande ce site : HSC : SSH et redirection X11. Je vous conseille également la lecture du site suivant, plus récent et peut-être plus accessible : Wednesday Why: Trusted and Untrusted X11 Forwarding with SSH.

Pour résumer : "It should be possible to run almost all clients as untrusted, leaving the trusted category for screencapture and screencast programs, macro recorders, and other specialized utilities." (cf : deuxième lien donné ci-dessus). Il convient donc d'utiliser le mode untrusted (ssh -X) plutôt que trusted (ssh -Y) afin d'augmenter un peu la sécurité.

Mais c'est plus compliqué que cela. Si la ligne "ForwardX11Trusted yes" est présente dans votre fichier ssh_config (coté client donc), alors ssh -X revient au même que ssh -Y : cela correspond au mode trusted. Veuillez donc a ce que la directive "ForwardX11Trusted" soit bien à "no" dans le fichier ssh_config du client et utilisez l'argument -X de SSH sauf si le client X11 n'est pas compatible avec le mode untrusted auquel cas, utilisez l'argument -Y.

Il n'y a rien a installer. Il ne reste plus qu'à vous connecter à votre serveur SSH :

ssh -X login@host
Si votre client est sous Windows

PuTTY permet également le X11 forwarding. Il faut aller dans le menu "SSH" puis dans "X11". Il faut cocher la case "Enable X11 forwarding". Pour choisir le protocole d'authentification en tout connaissance de cause, je vous conseille la lecture de ce site : Configuring PuTTY.

Ensuite, il vous faut une implémentation du serveur X pour Windows. A ma connaissance, il y a Xming ou Cygwin/X.

Ensuite, il ne vous reste plus qu'à initier la connexion au serveur SSH (bouton "Open").

Utiliser des applications graphiques

Forwarder quelques applications

Que votre client soit sous GNU\Linux ou sous Windows, vous pouvez lancer un programme graphique en utilisant cette syntaxe (dans le shell distant bien sûr) :

programme >/dev/null 2>&1 &

Par exemple :

firefox >/dev/null 2>&1 &

Explications : ">/dev/null 2>&1" permet de rediriger la sortie standard et la sortie d'erreur vers /dev/null afin de ne pas être saturé par des messages de debug/erreur. "&" permet de mettre l'application en arrière plan et donc de libérer le terminale et donc de pouvoir taper d'autres commandes (qu'elles lancent un programme graphique ou pas).

Forwarder un environnement graphique complet

Je pense que ce n'est pas la meilleure solution. Cela surcharge le trafic réseau inutilement car vous savez très bien les applications que vous voulez lancer et vous pouvez donc les lancer avec la méthode précédente. Si vous tenez à utiliser cette solution, activer au moins la compression de la connexion, lors de la connexion au serveur SSH, avec l'argument -C de ssh :

ssh -XC login@host

Avec gnome :

gnome-session >/dev/null 2>&1 &

Avec KDE (je n'ai pas testé puisque notre serveur Fedora est équipé de Gnome) :

startkde >/dev/null 2>&1 &

Là aussi, peu d'importance que le client soit sous un Unix ou sous un Windows.

Connexion via un serveur SSH intermédiaire

Il peut arriver que le serveur sur lequel on veut récupérer l'affichage soit derrière un pare-feu et que le seul moyen de traverser le pare-feu soit un autre serveur SSH.

Voici un schéma pour mieux comprendre ce qui va suivre (source : kuxon.org) :
schema connexion SSH complexe

En tout cas, seul l'étape de connexion au serveur change, le reste est identique. Le choix entre le mode trusted/untrusted reste d'actualité, avec les même enjeux qu'avec une connexion SSH directe.

On se connecte d'abord au serveur SSH qui sert de relai (serveur A sur l'image d'illustration) en activant le port forwarding local :

ssh -L2200:serveurB:22 loginA@serveurA

Puis on se connecte au serveur B, en activant le X11 forwarding :

ssh -X loginB@127.0.0.1 -p 2200

Cette commande est à taper sur le client, pas dans le shell distant de A, évidemment. loginA est le login sur le serveur A et loginB ... le login sur serveurB.

Et si on avait 2 serveurs intermédiaires ?

Le principe reste le même :

ssh -L2200:serveurB:22 loginA@serveurA
ssh -L22000:serveurC:22 loginB@127.0.0.1 -p 2200
ssh -XC loginC@127.0.0.1 -p 22000

Par contre, dans ce cas précis, l'empilement des couches réseau est abominable ... mais on a pas tous les jours besoin de se connecter en mode graphique et encore moins en passant via 2 serveurs intermédiaires.

Une dernière chose que vous devez vous demander : pourquoi avoir utiliser les images du site kuxon.org et ne pas appliquer la méthode que ce site propose ? Tout simplement parce que je n'ai pas réussi à faire fonctionner la méthode présentée par ce site.

Je signale également que l'idée d'utiliser le port forwarding afin de déporter l'affichage à travers un deuxième serveur SSH intermédiaire m'est venue à la consultation de cette page web où cette méthode y est écrite, succinctement : UNIX One-Liners.

Aucun commentaire.

Ajoutez votre commentaire