Lo hice y lo entendí

El blog de Vicente Navarro
04 nov

Mantener el reenvío de ventanas X de SSH tras hacer un su

Es muy común que sistemas UNIX/Linux a los que se accede por SSH no permitan acceso directo con root. Hay que autentificarse como un usuario normal y luego, si se necesita acceso de root, se usa su para obtener una shell de root. En sistemas con OpenSSH, en el fichero /etc/sshd/sshd_config encontraremos el parámetro PermitRootLogin, que está a “no” en muchos sistemas. Entre las ventajas de no permitir acceso directo de root está que el usuario -en teoría- no se pasará a root a menos que lo necesite y que queda registrado qué usuarios están/han estado en el sistema.

Pero esta configuración genera problemas con el reenvio de ventanas X11 a través de SSH. Por ejemplo, con sistemas HP-UX y Solaris (luego veremos qué pasa con Linux), cuando accedes por SSH con un usuario reenviando las ventanas X11 y luego haces un su, perdemos el túnel de X11:

$ ssh -X usuarioprueba@solx86
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
$
$ echo $DISPLAY
localhost:10.0
$
$ /usr/openwin/bin/xclock
$
$ su -
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
#
# echo $DISPLAY
#
# /usr/openwin/bin/xclock
Error: Can't open display:

Si ponemos a mano la variable $DISPLAY, el error pasará de ser que no puede acceder al display a que no tiene autorización para usar el display:

# DISPLAY=localhost:10.0
# export DISPLAY
# 
#  /usr/openwin/bin/xclock
X11 connection rejected because of wrong authentication.
X connection to localhost:10.0 broken (explicit kill or server shutdown).

Una solución, aprovechando que root puede acceder a los ficheros de todos los usuarios, es modificar la variable $XAUTHORITY para usar el fichero .Xauthority del usuario con el que entramos y no el de root:

# XAUTHORITY=/export/home/usuarioprueba/.Xauthority
# export XAUTHORITY
#
# /usr/openwin/bin/xclock

Al entrar a un sistema por SSH con la opción de reenvío de X11 activada, el servidor SSH añade una MIT-MAGIC-COOKIE-1 al fichero $HOME/.Xauthority para que sólo ese usuario (y no otros que estén conectados a la máquina e intenten usar el mismo $DISPLAY) pueda usar su túnel SSH para reenviar ventanas X11. Si el usuario root usa la misma magic cookie, pues podrá entrar sin problemas.

Otra opción para no reemplazar por completo el .Xauthority de root pasa por listar las magic cookies disponibles en el .Xauthority del usuario:

$ /usr/openwin/bin/xauth list
clientessh:0  MIT-MAGIC-COOKIE-1  e712f99f148d5bf00e5df9f345635434
sistemavncserver:1  MIT-MAGIC-COOKIE-1  d30c3ab6ca017837260ff6221fd80da7
solx86/unix:10  MIT-MAGIC-COOKIE-1  1d9076a2068a5e79d1259bea382cec2d

extraemos en formato binario sólo la entrada que nos interesa:

$  /usr/openwin/bin/xauth extract .Xauthority_solx86 solx86/unix:10

y ya como root, unimos la entrada a las existentes y ya podremos acceder al servidor X:

$ su -
Password:
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
# DISPLAY=localhost:10.0
# export DISPLAY
#
# /usr/openwin/bin/xauth merge /export/home/prueba/.Xauthority_solx86
#
# /usr/openwin/bin/xauth list
solx86/unix:10  MIT-MAGIC-COOKIE-1  1d9076a2068a5e79d1259bea382cec2d
#
# /usr/openwin/bin/xclock

Y otra opción más sería, tras listar las entradas existentes, simplemente añadir la magic cookie a mano en el .Xauthority de root:

# /usr/openwin/bin/xauth add solx86/unix:10  MIT-MAGIC-COOKIE-1  1d9076a2068a5e79d1259bea382cec2d
#
# /usr/openwin/bin/xclock

Decíamos que en Linux no tenemos este problema. Al pasarnos a root, la variable $DISPLAY se conserva y no necesitamos añadir la magic cookie para que el reenvío de ventanas X11, simplemente, siga funcionando:

# ssh -X usuariopruebap@rh5x64
usuariopruebap@rh5x64's password:
$
$ xclock
$
$ echo $DISPLAY
localhost:10.0
$
$ su -
Password:
[root@rh5x64 ~]# echo $DISPLAY
localhost:10.0

Esta magia de los sistemas Linux la proporciona el módulo PAM pam_xauth:

The pam_xauth PAM module is designed to forward xauth keys (sometimes referred to as “cookies”) between users.

Without pam_xauth, when xauth is enabled and a user uses the su(1) command to assume another user’s privileges, that user is no longer able to access the original user’s X display because the new user does not have the key needed to access the display. pam_xauth solves the problem by forwarding the key from the user running su (the source user) to the user whose identity the source user is assuming (the target user) when the session is created, and destroying the key when the session is torn down.

Así, en el fichero /etc/pam.d/su, típicamente encontraremos una línea como ésta:

session         optional        pam_xauth.so

El módulo guarda las magic cookies necesarias en diferentes ficheros $HOME/.xauth??????:

# xauth -f .xauthrBGj8r list
rh5x64/unix:10  MIT-MAGIC-COOKIE-1  aaceeca9bf499b5c85aba64a3ae42bd0

que, aunque normalmente se eliminan solos al salir, en ocasiones se quedan ahí abandonados. Por ello, en Google podemos encontrar bastantes casos de gente preguntando qué son dichos ficheros .xauthXXXXX y por qué tienen muchos.

Y para finalizar, una mención al Remote X Apps mini-HOWTO, en el que podremos repasar los conceptos básicos sobre cómo ejecutar aplicaciones X11 de un sistema en el servidor X de otro sistema UNIX/Linux.

:wq

Entradas relacionadas

8 Comentarios a “Mantener el reenvío de ventanas X de SSH tras hacer un su”

Trackbacks y pingbacks:

Tema LHYLE09, creado por Vicente Navarro