L’architecture X Window System s’appuie sur le model client/serveur :
Le serveur X gère l’affichage à l’écran et les évènements souris, clavier, etc.
Les clients, c’est à dire les applications, s’y connectent et décrivent comment elles doivent être dessinées. Le serveur X leur fournit les évènements utilisateurs : clic sur tel ou tel bouton, appuie sur telle touche, afin que les applications puissent y réagir….
Cette architecture client/serveur est très pratique car les clients (=applications) ne se trouvent pas forcément sur l’ordinateur où il y a le serveur X : c’est la redirection d’affichage.
Dans cet article, nous allons étudier deux méthodes de redirection d’affichage, ainsi que leurs avantages et défauts.
Pour que les choses soient bien clairs, on va nommer l’ordinateur où s’exécutent les applications ‘tombouctou‘ et l’ordinateur où se fait l’affichage ‘Sophia‘.
Pensez à vérifier, tout au long de l’article, que les ports utilisés sont bien redirigés si vous êtes derrière un routeur, et que votre firewall est configuré pour y laisser passer le traffic !
1/ La variable d’environnement DISPLAY :
La variable DISPLAY est une variable d’environnement qui indique aux applications le serveur X auquel elles doivent se connecter.
Elle se présente sous la forme suivante : ordinateur:numero_serveur_x.numero_ecran
ordinateur : c’est l’ordinateur sur lequel on veut que l’affichage se fasse (on peut mettre une ip ou un dns). Si ce champ est vide, c’est localhost par défaut.
numero_serveur : c’est le numéro du serveur X avec lequel l’application va se connecter. C’est donc 0, sauf si vous avez lancé plusieurs serveurs X en même temps. Ce numéro permet à l’application de connaître le port sur lequel elle doit se connecter pour accéder au serveur X. Le numéro du port est obtenu en additionnant 6000 + le numéro du serveur X. Exemple : pour se connecter en local au serveur X numéro 0, le client ouvre une socket TCP sur le port 6000, pour le serveur X numéro 1 c’est le port 6001, etc…
numero_ecran : le numéro de l’écran, c’est donc généralement 0.
On peut consulter la valeur de la variable DISPLAY :
$ echo $DISPLAY
:0.0
Içi les applications s’affichent donc en local, sur le serveur X numéro 0, et l’écran principal. On peut vérifier que le serveur X est bien à l’écoute sur le port n°6000 :
$ sudo netstat -tlnp | grep X
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN 5978/X
tcp6 0 0 :::6000 :::* LISTEN 5978/X
2/ Redirection native avec la variable DISPLAY.
Mettons nous d’accord de suite sur les avantages/inconvéniants de cette méthode :
Inconvéniants : cette méthode est dangereuse pour les raisons suivantes :
- Le trafic X passe en clair sur le réseau ! Il est alors possible de snifer le réseau et par exemple enregistrer les frappes de touches (keylogger). C’est donc absolument à bannir sur internet !
- Xhost est peu sécurisé : il autorise/interdit un ordinateur à se connecter, sans aucune distinction entre les différents utilisateurs de cette machine.
Avantages :
- Méthode de redirection ayant la meilleur performance (pas de cryptage).
- simple et rapide, elle dépanne souvent.
Vous voulez rediriger l’affichage de l’ordinateur tombouctou sur l’ordinateur sophia. Vous avez donc ouvert une connection ssh de sophia sur tombouctou, avec la commande « ssh maSession@tombouctou« .
Vous avez alors un shell sur tombouctou et il faut changer la variable DISPLAY de ce shell pour qu’elle indique le serveur X de l’ordinateur sophia : « export DISPLAY=sophia:0.0« .
Maintenant vous tentez d’ouvrir gedit : « gedit & » et paf, c’est le drame : « Can’t open DISPLAY« .
Du calme, c’est normal. S’il suffisait de changer la variable DISPLAY, tout le monde pourrait ouvrir des fenêtres sur n’importe quel ordinateur du réseau…
Il faut donc autoriser l’ordinateur tombouctou à afficher des fenêtres sur sophia.
Dans un shell sur l’ordinateur sophia entrez en tant que simple utilisateur :
$ xhost + ip_tombouctou
XXX.XXX.XXX.XXX being added to access control list
xhost est le programme qui contrôle la liste des ordinateurs qui sont autorisés à se connecter au seveur X de la machine. ‘+’ ajoute un ordinateur à la liste, ‘-‘ l’enlève.
Attention : ne JAMAIS entrer simplement « xhost + » qui autorise n’importe qui à se connecter au serveur X !
Vous pouvez maintenant réessayer d’ouvrir gedit dans le shell sur tombouctou : « gedit & » et magie, magie, vos idées ont du génie, la fenêtre s’ouvre sur sophia !
Attention, sur les systèmes à base de Debian, le serveur X est lancé avec l’option « -nolisten tcp » par défaut. Cette option indique au serveur X de ne pas accepter de connexions clientes non locale, ce qui empêche la redirection d’affichage.
Pour connaître les options avec lequelles le serveur X a été lancé :
$ ps aux | grep "/bin/X" | grep -v "grep"
Pour enlever l’option « -nolisten« , il faut éditer le fichier de configuration de l’environnement de bureau que vous utilisez :
- Pour Gnome, il faut changer ‘DisallowTCP=true‘ en ‘DisallowTCP=false‘ dans le fichier /etc/gdm/gdm.conf, ce que fais la commande suivante :
sudo sed -ie 's/DisallowTCP=.*$/DisallowTCP=false/' /etc/gdm/gdm.conf.
- Pour KDE, il faut éditer le fichier /etc/kde3/kdm/kdmrc et retirer ‘-nolisten tcp‘ de la ligne ‘ServerArgsLocal=-nolisten tcp‘.
Ensuite il faut relancer le serveur X :
kill -HUP `ps aux | grep "/bin/X" | grep -v "grep" | awk '{print $2;}'`
(un ctrl-alt-backspace ne suffit pas). Pensez à enregistrer vos documents avant d’exécuter la commande !
3/ Redirection automatique avec SSH
Simple, rapide, sécurisé, c’est LA méthode à utiliser!
SSH permet l’encapsulation de flux : il sécurise le transfert d’informations de manière transparente pour l’utilisateur en cryptant le flux à l’émission et en le décryptant à la réception.
Cette méthode est sécurisée car le flux X11 sera donc crypté par ssh, et l’on bénéficie des systèmes de sécurité (clef publique/privée) mis en place par ssh.
La mise en oeuvre, elle, est très simple :
ssh -X user@tombouctou
(à taper sur l’ordinateur sophia).
SSH s’occupe pour vous de changer la variable DISPLAY dans la session ouverte sur tombouctou. En fait il lui donne la valeur ‘localhost:10.0‘ afin que les clients X se connectent sur le port 6010. C’est sur ce port que le démon sshd récupère le flux X11 pour le crypter et l’envoyer dans le tunnel SSH. À la réception sur l’ordinateur distant, le flux est décrypté et redirigé sur le port 6000 où il atteint bien le serveur X distant.
(Le schéma montre un sens avec les flèches pour faciliter la compréhension, mais le tunnel ssh est bidirectionnel.)
Ce mécanisme est donc complexe, mais la mise en oeuvre est très aisée : un simple ‘-X‘ dans la ligne de commande. Il faut cependant que le démon ssh soit configuré en positionnant l’option ‘X11forwarding‘ à ‘yes‘ dans le fichier /etc/ssh/sshd_config. (C’est le cas par défaut sur beaucoup de distributions, sinon effectuez la modification et pensez à redémarrer le démon ssh : ‘sudo /etc/init.d/ssh restart’).
Le point faible de cette méthode est qu’elle charge un peu plus le CPU des machines, à cause du cryptage/décryptage à la volée, assuré par SSH.
La performance sera alors moindre si vous utilisez de vieux ordinateurs, et il vaudrait alors mieux se tourner vers la première solution si le réseau est sûr.
3/ Redirection de l’environnement graphique (XDMCP)
Içi, au lieu de rediriger l’affichage d’une application, on redirige l’affichage de l’environnement graphique complet. On peut donc se logguer à distance en mode graphique. Cela s’appel le XDMCP : X Display Manager Control Protocol. Pour info, le port udp 177 est utilisé.
Par défaut, le xdmcp est désactivé car le flux X11 passe là aussi en clair, et c’est donc dangereux sur des réseaux non sécurisé.
Par contre il est très simple de l’activer, pour l’utiliser par exemple au travail (réseau protégé par un pare-feu). Il faut donc l’activer sur le serveur :
- Pour gnome, il faut éditer le fichier /etc/gdm/gdm.conf et changer ‘Enable=false‘ en ‘Enable=true‘.
- Pour kde, même manipulation, mais dans le fichier /etc/kde3/kdm/kdmrc .
Ensuite pour s’y connecter à partir du client, il y a comme toujours deux méthodes :
- Graphiquement : il suffit d’aller cliquer sur « Connexion distante via XDMCP » dans le menu « Options » lors de l’apparition du GDM (Gnome Desktop Manager. Vous arrivez alors sur une fenêtre où les serveurs xdmcp sont listés. Si le votre n’apparait pas, vous pouvez l’ajouter manuellement.
- En console : il faut basculer sur un terminal virtuel (de Ctrl+Alt+F1à Ctrl+Alt+F6), se logguer et lancer un (nouveau) serveur X, avec l’option ‘-query‘ :
startx -- :1 -query 192.168.1.2
Içi le ‘:1‘ sert à lancer un second serveur X (rappeler vous : le premier serveur X est identifié par le numéro 0). Le serveur X lancé par défaut est toujours accessible par Ctrl+Alt+F7.
Sachez qu’il est possible de lancer automatiquement le serveur X en xdmcp. Très pratique si vous avez un vieil ordinateur, celui-ci ne s’occupe que de l’affichage et c’est la bête de course de la maison qui calcule !
4/ Autres alternatives ….
Il existe encore d’autre alternatives, parmi lesquelles on peut citer le couple x11vnc / vncviewer, mais aussi FreeNX…..
{jcomments on}