GuiGui's show

Table des matières

Ce billet fait suite à celui-ci : SSH : du port forwarding au VPN bon marché. J'y évoquais les problématiques de fuite des requêtes de résolution de nom via le protocole DNS. Mais je n'ai pas abordé un point sur lequel je m'interroge depuis quelques temps : je me demandais si les requêtes de résolution étaient envoyées au résolveur DNS défini dans le fichier /etc/resolv.conf du client SSH ou à celui défini dans le fichier du serveur SSH. Il paraît presque évident que c'est le résolveur définit sur le serveur qui sera utilisé.

Ayant sévèrement planté mon WRT54GL, j'en ai profité pour le flasher avec la déclinaison brcm2.4 d'OpenWRT. Cette déclinaison étant plus compact, j'ai pu installer tcpdump sur mon routeur et vérifier tout ceci.

Pourquoi ce test ?

Si votre ordinateur reçoit automatiquement l'adresse IP du résolveur DNS par le serveur DHCP du réseau insecure, que ce résolveur fait partit du réseau insecure et en admettant que les requêtes DNS sont envoyées à ce résolveur via votre serveur SSH, alors l'administrateur réseau du réseau insecure pourra faire un croisement entre l'adresse IP qui effectue les résolutions DNS sur le résolveur DNS interne (qui sera celle de votre serveur SSH) et l'adresse IP de destination du trafic SSH (là aussi, ce sera celle de votre serveur). Il pourra donc savoir quels noms de domaine vous avez résolus et par voie de conséquence, ce que vous avez fait sur internet. La redirection dynamique via SSH serait donc moins efficace. Comme déjà dit, il est peu probable que les résolutions de noms se fasse via le résolveur défini dans le fichier /etc/resolv.conf du client, mais cela ne coute rien de s'en assurer.

Mise en place du test

Évidemment, ce test ne sera pas effectué depuis un réseau dont vous n'avez pas confiance ...

D'abord, on installe tcpdump sur le WRT54GL :

opkg update
opkg install tcpdump

Sur la machine de test, on prépare un tsark/wireshark/tcpdump et un Firefox avec un proxy défini dans les paramètres et l'option network.proxy.socks_remote_dns à true dans le about:config.

Note : il n'est pas nécessaire de faire une capture du trafic réseau sur la machine de test si on est déjà convaincu que le trafic passera bien par le tunnel SSH. Je propose ici de faire une capture afin que les septiques puissent vérifier par eux-mêmes ce que je disais dans le billet sus-cité.

Ensuite, on définie un résolveur DNS différent sur le routeur et sur la machine.
Disons que sur la machine, nous utiliserons le résolveur d'OpenDNS : "nameserver 208.67.222.222" à mettre dans le fichier /etc/resolv.conf.
Disons que sur le routeur nous utiliserons le résolveur de Google : "nameserver 8.8.8.8" à mettre dans le fichier /etc/resolv.conf.

On redémarre ensuite dropbear (ou autre serveur SSH) sur le routeur :

/etc/init.d/dropbear/restart

On se déconnecte puis reconnecte au routeur via SSH, en activant la redirection dynamique.

On lance la capture, que nous appellerons capture R par la suite, sur le routeur (voici un tutoriel pour tcpdump):

tcpdump -i eth0.1 not port 22 -s0 -w capture.cap

Explication : tcpdump écoute sur l'interface wan (eth0.1), ne garde pas les messages correspondant à la session SSH, ne tronque pas les paquets et enregistre le trafic dans le fichier capture.cap.

On lance la capture, que nous appellerons capture M par la suite, sur la machine.

Dans Firefox, tentez d'accéder à n'importe quel site, de préférence un site sur lequel vous n'avez pas l'habitude d'aller.

On récupère la capture :

scp root@routeur:/root/capture.cap .

On analyse la capture avec Wireshark (vous pouvez bien sur le faire avec tsark/tcpdump. Dans ce cas là, inutile de rapatrier la capture sur votre machine) :

wireshark capture.cap

Résultat attendu

Capture M ne doit contenir que du trafic SSH et TCP (ack). Capture R doit contenir du trafic HTTP, TCP (ack) et du trafic DNS vers 8.8.8.8 et surtout pas vers 208.67.222.222.

Résultat obtenu

Exactement le résultat attendu. Firefox dirige les requêtes DNS vers le résolveur défini dans le fichier /etc/resolv.conf du serveur SSH au moment où le serveur SSH a été lancé sur la machine (d'où l'intérêt d'avoir redémarré le serveur SSH lors de la mise en place du test).

Le cas proxychains

Pour les applications ne prenant nativement pas en charge les proxy SOCKS et/ou le transfert des requêtes DNS vers ce proxy, il est, comme nous l'avons dit dans l'article sus-cité, nécessaire de faire appel à un wrapper SOCKS (proxychains, tsocks, torsocks, etc.). Le comportement envers les requêtes DNS dépendra du wrapper choisit.

Dans le cas de proxychains, les requêtes sont toutes envoyées au même résolveur : 4.2.2.2.

Vous pensez bien que je trouve cela intolérable : si j'ai installé un résolveur DNS sur mon WRT54GL, c'est pour l'utiliser (pour les raisons évoquées dans l'article linké).

Je me suis donc dis que ce résolveur devait bien être défini dans les sources de proxychains. J'avais dans l'idée de recompiler les sources après avoir changé l'adresse du résolveur utilisé.

J'ai donc téléchargé et décompressé les sources :

wget http://downloads.sourceforge.net/project/proxychains/proxychains/version%203.1/proxychains-3.1.tar.gz?r=&ts=1294602235&use_mirror=mesh
tar -xf proxychains-3.1.tar.gz

On cherche ensuite l'occurrence "4.2.2.2" dans les sources :

cd proxychains-3.1
find ./ -type f -exec bash -c "grep "4.2.2.2" {} && echo {}" \;

Find/grep trouvent un résultat dans le fichier ./proxychains/proxyresolv. On affiche son contenu :

cat ./proxychains/proxyresolv

Je vous quote le passage intéressant en vous invitant quand même à lire la suite du fichier qui est intéressante puisqu'elle permet de comprendre que proxychains résout les noms de domaine avec une méthode toute simple qui fait plaisir à voir :

#!/bin/sh
# This script is called by proxychains to resolve DNS names
 
# DNS server used to resolve names
DNS_SERVER=4.2.2.2

Tout devient clair : proxychains se sert de ce script shell pour résoudre les noms de domaine. Il doit suffire de changer le contenu de la variable DNS_SERVER pour changer de résolveur.

On se dit que ce script ne sera pas compilé et donc qu'il doit y en avoir un exemplaire sur notre machine qui sert au proxychains installé :

sudo find / -type f -name "proxyresolv"

Find nous trouve un résultat : /usr/lib/proxychains3/proxyresolv.

On modifie donc ce fichier en remplaçant 4.2.2.2 par l'adresse du résolveur DNS voulu. Pour ma part, ça sera le résolveur installé sur mon routeur donc 192.168.1.1 (adresse lan par défaut).

On refait ensuite le test effectué précédemment sauf qu'au lieu d'utiliser Firefox, on utilise un programme proxychainé ("proxychains programme").

On voit, dans la capture réseau de R, que c'est bien le résolveur déclaré dans le script /usr/lib/proxychains3/proxyresolv qui est utilisé. Pour ceux qui veulent une preuve de plus : pour peu que vous ayez lancé la commande depuis une console, vous pouvez lire quelquechose comme ça :

|S-chain|-<>-127.0.0.1:6666-<><>-192.168.1.1:53-<><>-OK"

Je profite de ce premier billet de l'année pour vous souhaiter une bonne année 2011 et surtout une bonne santé.

Passons maintenant aux choses sérieuses. J'utilise Piwik depuis bientôt un an et j'en suis satisfait. Récement, la version 1.1 puis la 1.1.1 ont fait leur apparition. La 1.1 apporte son lot de bugs corrigés, de nouvelles fonctionnalités ainsi que son lot de failles de sécurité corrigées. La version 1.1.1 corrige également quelques bugs.

D'habitude, les mises à jour se font sans soucis, c'est pour cela que je n'écris jamais de billet à ce sujet. Mais cette fois-ci, j'ai eu le droit à tout les problèmes.

Après une mise à jour manuelle de la version 1.0 vers la version 1.1.1, je ne peux plus me connecter. Le titre de la page est correcte, du HTML est visible dans la source de la page mais rien ne s'affiche. Ce problème est connu mais la solution proposée ne fonctionne pas (en même temps, je n'utilise pas de reverse proxy ...). J'ai également vidé le cache de mon navigateur et supprimé les cookies, comme conseillé un peu partout, mais sans succès.

Je décide donc d'installer une version saine et complète (comprendre que ma version de production est optimisée : j'enlève un certains nombres de plugins que je juge inutiles pour mon usage, nous y reviendrons) en parallèle à ma version 1.0 de production. Cette fois-ci, la connexion fonctionne.

EDIT 06/01 23h55 : Je viens de trouver une solution à ce premier "problème" : il faut activer le javascript dans votre navigateur. Si vous utilisez une extension/widget dans le genre de NoScript, pensez à autoriser le javascript sur votre page d'authentification Piwik. Sans javascript, pas d'affichage. Lors de l'installation d'une version saine et complète, j'ai du activer le javascript sur le domaine de test, ce qui explique pourquoi le formulaire est apparu.

Mais, un deuxième problème arrive alors : je me retrouve avec des pages de texte, comme si il manquait le CSS ou les images associées et ce, sur toutes les pages. Je vérifie mon client FTP : tous les fichiers ont pourtant bien été transférés. Je regarde rapidement sur internet : un problème similaire est connu. Je tente encore une fois de vider le cache de mon navigateur et de supprimer les cookies, sans plus de succès. Le patch proposé dans le lien donné ci-dessus est sans effet : la modification était déjà effectuée dans le latest.zip que j'ai téléchargé.

Je décide de prendre la dernière révision disponible (la 3645, qui correspond a la version 1.1.2b1) sur le SVN du projet :

sudo apt-get install subversion
mkdir piwik-svn
cd piwik-svn
svn checkout http://dev.piwik.org/svn/trunk

find ./ -type d -name .svn -exec rm -rf {} \;
rm -rf ./trunk/tests

"find ./ -name ".svn" -exec rm -rf {} \;" permet de supprimer les dossiers cachés créés par subversion qui ne serviront pas. Ne tenez pas compte des messages d'erreur "Aucun fichier ou dossier de ce type" car les dossiers seront quand même supprimés.

"rm -rf ./trunk/tests" permet de supprimer le dossier "tests" qui ne sert pas non plus.

Ensuite, vous pouvez supprimer les plugins que vous ne comptez pas utiliser. A titre d'information, je supprime :

• AnonymizeIP
• DBStats
• ExampleAPI
• ExampleFeedburner
• ExamplePlugin
• ExampleRssWidget
• Feedback
• Goals
• Live
• MultiSites
• PDFReports
• SecurityInfo (à utiliser quand même une fois avant de le supprimer)
• UserCountryMap
• VisitorGenerator
• Widgetize

Penser à adapter vos fichiers global.ini.php et config.ini.php : enlevez les lignes "Plugins[] = xxxxxxxx", et/ou "PluginsInstalled[] = xxxxxxxx" et/ou "Plugins_Tracker[] = xxxxxxxx" qui correspondent à des plugins que vous avez supprimés. Si vous sautez cette étape, vous obtiendrez des messages d'erreurs explicites.

Il ne vous reste plus qu'à uploader le contenu du dossier trunk sur votre serveur web et à installer Piwik en suivant l'assistant, comme lors de la première fois.

Pour la base de données, ne vous inquiétez pas : Piwik verra que les tables existent déjà et vous demandera si vous voulez les utiliser ou si vous voulez les effacer. En choisissant de les réutiliser, vous conservez vos stats.

EDIT 06/01 23h55 : Pour le premier problème et en attendant une solution officielle, une solution est donnée plus haut. Pour le deuxième problème, il semble avoir été corrigé dans la révision 3645 (et donc dans la version 1.1.2b1) puisque je ne l'ai pas rencontré de nouveau.

Un dernier billet sur SSH, sinon nous (vous et moi) allons être en overdose 😛 .

Si vous avez désactivé IPv6 sur votre machine GNU/Linux dans l'attente que votre FAI vous ouvre les portes du vrai internet IPv6 (sans tunnel 6to4 j'entends) et que vous tentez une redirection locale/distante/dynamique avec SSH, vous obtiendrez le message suivant : "bind: Cannot assign requested address".

Pour résoudre ce petit soucis, il faut dire à votre client SSH de ne travailler que sur le protocole ipv4. Pour cela, il existe au moins deux méthodes, si on en croit le man SSH :

• Utiliser l'option "-4" lors de votre connexion au serveur :

  ssh -4 -NL8080:127.0.0.1:3128 login@host

  Néanmoins, cette solution est peu pratique étant donné qu'il faut utiliser l'option lors de chaque connexion.

• Ajouter une ligne "AddressFamily inet" dans le fichier ssh_config.

Table des matières

Quand je suis sur un réseau insecure (wifi, dont la charte précise que des contrôle techniques de bon usage du réseau peuvent être effectués sans préavis, etc. ), je sécurise mes connexions grâce à SSH et à ses fonctionnalités de port forwarding / tunnels. Dans cet article, je souhaite vous faire un retour sur mes découvertes plus ou moins récentes.

Voici une page web qui explique clairement le principe du port forwarding avec SSH et la différence entre une redirection locale (ssh -L) et une redirection distante (ssh -R) : Tynsoe projects.

La redirection locale

Au commencement, j'utilisais une redirection locale afin de rediriger ma navigation internet sur un proxy Squid se trouvant sur un serveur "at home". Donc une bête ligne de commande comme celle-ci suffisait :

ssh -NL8080:localhost:3128 login@host

Ensuite, je configurais mon navigateur pour utiliser le proxy HTTP/HTTPS suivant :

• Hôte : 127.0.0.1
• Port : 6666

Et dans les rares cas ou j'avais besoin d'un autre service, je transférais un autre port en même temps :

ssh -NL8080:localhost:3128 -L2200:serveurSSH:22 login@host

Je pouvais alors surfer tranquillement et me connecter à la machine serveurSSH via l'adresse 127.0.0.1:2200

La redirection dynamique

Ensuite, j'ai voulu utiliser plus de services (mail, messagerie instantané, etc.) et j'ai donc trouvé les limites de la redirection locale de ports (transférer tous ces ports à la mano c'est pas top). De plus, mon serveur proxy était en panne. Mais j'ai découvert la redirection dynamique (ssh -D). Du coup, c'est mon fidèle WRT54GL qui me sert de proxy.

Maintenant, une simple ligne de commande suffit pour avoir accès à tous mes services :

ssh -ND 6666 login@host

Ensuite, il faut définir un proxy SOCKS dans les paramètres de chaque application dont vous avez besoin :

• Hôte : 127.0.0.1
• Port : 6666

Remplacez 6666 par le port que vous avez choisi lors de l'initialisation de la connexion SSH.

Se pose une première problématique : que faire si l'application ne possède pas une telle option ?
Se pose ensuite une seconde problématique : certains applications n'utilise pas le proxy pour faire transiter certaines informations. C'est typiquement le cas de la résolution d'un nom de domaine via le protocole DNS. A quoi peut bien servir un tunnel si le réseau insecure arrive encore à voir une partie de notre trafic réseau ?

Ces deux questions trouvent la même réponse : il faut utiliser un programme qui capture les "appels réseau" d'un programme et force la redirection de ceux-ci dans le tunnel SSH. Il en existe plusieurs : tsocks, torsocks, proxychains, etc. . Il fait néanmoins faire attention : certains laisse encore passer les fameuses requêtes DNS entre les mailles de leur filet. Personnellement, j'utilise proxychains et je n'ai jamais rencontré de problèmes.

EDIT 09/01/2011 19h35 : Il faut dire aussi que mon choix pour proxychains a été influencé par les différents inconvénients qui apparaissent sur les alternatives :

• La version de tsocks disponible sur sourceforge laisse fuiter les résolutions DNS, à moins d'appliquer un patch. De plus, je rencontre beaucoup d'erreur de segmentation avec des applications courantes
• Torsocks me sort une erreur de segmentation pour quelques uns de mes programmes. Néanmoins, il y a quand même des progrès, par rapport à tsocks, sur ce point là.
• Dsocks me paraissait un peu "brouillon" avec son script python servant de forwardeur DNS. De plus, le script ne fonctionne pas et me lève des exceptions.
• Socat est une alternative que je n'ai pas essayé mais qui me parait plus que correcte mais lourde à utiliser.

Le fichier de configuration (/etc/proxychains.conf) est d'une simplicité enfantine. Voici le mien (j'ai supprimé quelques commentaires mais je vous invite à les lire dans votre fichier) :

# Strict - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# all proxies must be online to play in chain
# otherwise EINTR is returned to the app
strict_chain

# Quiet mode (no output from library)
quiet_mode

# Proxy DNS requests - no leak for DNS data
proxy_dns

[ProxyList]
socks5 127.0.0.1 6666

Il ne vous reste plus qu'à utiliser proxychains :

proxychains firefox
proxychains thunderbird
proxychains filezilla
proxychains pidgin
...
sudo proxychains apt-get update/install

Il ne vous reste plus qu'à modifier les raccourcis de votre menu (Gnome, KDE, etc.) afin d'inclure proxychains dans la commande à lancer pour les programmes dont vous souhaitez qu'il passent via le tunnel SSH.

A noter quand même que certains logiciels jouent le jeu et ne laisse pas filer les requêtes DNS, même sans utiliser proxychains. C'est le cas par exemple de Firefox, une fois la valeur "true" passée à l'option booléenne "network.proxy.socks_remote_dns" dans le about:config. Par contre, je n'ai pas constaté d'améliorations en faisant la même manipulation sous Thunderbird.

EDIT 09/01/2011 22h00 : Pour plus d'information sur le transfert des requêtes DNS via un proxy SOCKS, voir cet article : SSH, redirection dynamique, proxychains et DNS.

Vous comprenez que votre meilleur ami ici sera Tsark/Wireshark (ou n'importe quel autre programme d'analyse du trafic réseau), afin de tester qu'aucun flux transite en clair. Il apparait évident de procéder à ces tests avant d'aller dans le réseau insecure. Un iptables correctement paramétré permet également d'éviter les fuites causées par les démons ou par les programmes que l'utilisateur aurait oublié de proxyfier. Voir ce billet à ce sujet : Configuration rapide d’iptables pour les réseaux insecures.

ÉDIT 23/02/2011 22h45 :

Lorsque vous n'utilisez pas votre tunnel SSH, la connexion est fermée automatiquement. Pour maintenir la connexion, il suffit de se rappeler de la notion de keepalive.

Encore une fois, je ne réinventerai pas la roue puisqu'une recherche sur Google vous conduira sur ce blog : Aaron Toponce : Keeping Your SSH Connection Alive.

J'ajouterai cependant que vous pouvez définir le paramètre "ServerAliveInterval" dans le fichier /etc/ssh/ssh_config, ce qui évite de le répéter lors de chaque connexion. Personnellement, je définis un intervalle de 5 minutes soit 300 secondes : c'est amplement suffisant pour maintenir la connexion.

Si toute cette méthode vous semble encore trop contraignante, il vous reste encore la possibilité de vous monter un VPN avec OpenVPN. Je me suis penché sur cette alternative mais, malheureusement, mon WRT54GL n'a pas assez d'espace libre pour accueillir la libssl nécessaire au fonctionnement d'OpenVPN. Donc je n'ai pas creusé le sujet plus loin. Néanmoins, excellents tutoriel existent sur le net.

Un VPN bon marché avec SSH

Il y a quelques jours, je me disais qu'il devait y avoir un moyen de s'amuser avec SSH et les interfaces tun/tap. Je me tourne vers mon ami Google afin d'avoir une idée sur la marche à suivre. Je découvre alors que d'autres personnes ont eu mon idée depuis bien longtemps et notamment les développeurs d'openSSH qui permet, depuis sa version 4.3, de créer un tunnel de niveau 3 grâce aux interfaces virtuelles tun. Si j'étais un "artiste" ou un patent troll, je porterai plainte ... oser me voler mon idée que je n'avais pas à l'époque, c'est quand même scandaleux ! 😉 .

Voici les tutoriels qui m'ont éclairés sur le sujet :

• PointSlash : VPN avec SSH
• The TechSucks TechBlog : [Solutions] secure outside communication in insecure environments
• Debian Administration : Setting up a Layer 3 tunneling VPN with using OpenSSH
• Community Ubuntu Documentation : SSH_VPN

J'ai évidemment voulu tester tout ça, en utilisant la méthode manuelle (sans ifup), avec une machine virtuelle, avant une mise en production sur mon WRT54GL. Il n'y a aucune difficulté et ça fonctionne très bien (avec la machine virtuelle).

Malheureusement, dropbear, le serveur ssh allégé fourni par défaut avec OpenWRT, ne supporte pas ce type de tunnel. Installer OpenSSH sur mon routeur pose le même problème que celui de l'installation d'OpenVPN : la nécessaire libssl est trop lourde.

Donc je suis contraint d'utiliser un tunnel dynamique pour sécuriser mes connexions depuis un réseau insecure. Pour l'instant, cela me convient. Mais il faudra quand même que je songe à greffer une carte mémoire à mon WRT54GL.

Une dernière chose : comme signalé dans les commentaires de Debian Administration ou sur la page de la Community Ubuntu Documentation, la méthode de VPN over SSH n'est pas la meilleure solution du fait que le protocole SSH repose sur TCP et que l'on va faire circuler des trames TCP dans ce tunnel. Cette solution est impeccable quand il n'y a pas de problèmes sur le(s) réseau(x) traversé(s), mais dans le cas d'une perte de paquet, on assiste à un effondrement interne de la connexion. C'est pour cela qu'il veut mieux utiliser un VPN basé sur OpenVPN, configuré en UDP, bien entendu.

Je vous invite à lire ces deux documents, le deuxième étant la traduction, en français, du premier, afin d'avoir plus d'informations sur le sujet :

• Why TCP Over TCP Is A Bad Idea
• TCP over TCP ?

Note : dans cet article, je me préoccupe des systèmes UNIX/UNIX-like. Mais sous Windows, PuTTY permet la redirection locale, distante et dynamique. Ensuite, il doit exister des équivalents de proxychains, torsocks. Enfin, cygwin doit permettre de monter un VPN over SSH mais je ne me suis pas renseigné sur ce point.

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) :

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) :

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.