Le X11 forwarding est une fonctionnalité très pratique du client ssh (appelée par l'option -X), qui permet d'assurer une gestion automatique de l'export de display et de faire transiter les informations X11 dans la session ssh, améliorant donc considérablement la sécurité de l'ensemble.

Malheureusement, sur Solaris, il peut arriver que ça ne marche pas. Voici quelques erreurs courantes et leurs solutions.

En théorie

Quand ça marche, ça ressemble à ça :
amber# ssh -X chaos Sun Microsystems Inc. SunOS 5.10 Generic January 2005 chaos#echo $DISPLAY localhost:15.0 chaos# xterm [grande magie, la xterm apparaît]

Pas de positionnement du DISPLAY

Il peut arriver que le positionnement de la variable DISPLAY ne se fasse pas correctement.
amber# ssh -X chaos Sun Microsystems Inc. SunOS 5.10 Generic January 2005 chaos# echo $DISPLAY chaos# xterm xterm Xt error: Can't open display:

Il se peut bien sûr qu'il y ait un oubli dans la configuration (typiquement /etc/ssh/sshd_config), notamment :

X11Forwarding yes

En admettant que la configuration soit correcte, ce problème peut également provenir de la gestion d'IPv6, le tunnel SSH ciblant un port sur le localhost, mais résolvant localhost sur son adresse IPv6, qui n'est pas forcément configurée. On peut le contourner de deux façons différentes.

Correction du support IPv6

Il faut ajouter l'entrée suivante au fichier /etc/hosts si elle n'y figure pas déjà :
::1 localhost
Il faut ensuite monter l'interface loopback en IPv6 :
chaos# ifconfig lo0 inet6 plumb up
Bien entendu, il faudra ensuite s'assurer que l'interface soit montée à chaque reboot.

Binding du sshd en IPv4 seulement

L'autre solution pour contourner le problème consiste à indiquer à sshd de se binder uniquement sur IPv4, soit par le biais de son fichier de configuration, soit éventuellement directement au lancement du daemon.

Dans le premier cas, on met dans le sshd_config :
AddressFamily inet
Dans le second, en Solaris 10, on modifie le fichier /lib/svc/method/sshd en remplaçant :
'start') /usr/local/sbin/sshd ;;
par
'start') /usr/local/sbin/sshd -4 ;;

Pour les versions précédentes de Solaris, c'est le même principe mais en modifiant les scripts de démarrage dans /etc/init.d.

Bien évidemment, une fois la modification de configuration effectuée, il faut rafraîchir le service.

Authentification rejetée

Une fois que la variable d'environnement est bien exportée, il peut rester un problème d'authentification au niveau X11.

amber# ssh -X chaos chaos# echo $DISPLAY localhost:10.0 chaos# xterm X11 connection rejected because of wrong authentication. X connection to localhost:10.0 broken (explicit kill or server shutdown).
Pour un utilisateur de Putty, l'erreur se présentera plutôt sous la forme suivante :
c:\> plink -X merlin@chaos /usr/openwin/bin/xterm -ls</span> Xlib: connection to "localhost:10.0" refused by server Xlib: PuTTY X11 proxy: MIT-MAGIC-COOKIE-1 data did not match xterm Xt error: Can't open display: localhost:10.0

Ce problème provient typiquement de la présence d'un script sshrc (typiquement /etc/ssh/sshrc) ou $HOME/.ssh/rc. La présence de ces scripts est parfaitement légale, mais, s'ils existent, c'est alors à eux de gérer manuellement l'authentification X11 en appelant xauth. La solution peut être alors, au choix, de supprimer purement et simplement le fichier incriminé, ou d'y inclure la gestion xauth, comme indiqué dans le man de sshd (en version OpenSSH, ce n'est pas détaillé dans la version fournie avec l'OS) :

SSHRC If the file ~/.ssh/rc exists, sh(1) runs it after reading the environment files but before starting the user's shell or command. It must not produce any output on stdout; stderr must be used instead. If X11 forwarding is in use, it will receive the "proto cookie" pair in its standard input (and DISPLAY in its environment). The script must call xauth(1) because sshd will not run xauth automatically to add X11 cookies. The primary purpose of this file is to run any initializa- tion routines which may be needed before the user's home directory becomes accessible; AFS is a particular example of such an environment. This file will probably contain some initialization code followed by something similar to: if read proto cookie &amp;&amp; [ -n "$DISPLAY" ]; then if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then # X11UseLocalhost=yes echo add unix:`echo $DISPLAY | cut -c11-` $proto $cookie else # X11UseLocalhost=no echo add $DISPLAY $proto $cookie fi | xauth -q - fi If this file does not exist, /usr/local/etc/sshrc is run, and if that does not exist either, xauth is used to add the cookie.