COMO: Parte 3 - Aprovechar lo que ofrece ssh para desplegar aplicaciones remotas

Imagen de acl

En las partes anteriores, aprendimos cómo decirle a una aplicación cuál es el servidor que va a mostrar sus gráficos y aprendimos a manejar el control de acceso que provee X para evitar arbitrariedades.

Ahora vamos a ir un paso más allá y vamos a ver en mayor detalle cómo podemos correr aplicaciones remotas usando ssh como capa de transporte. En el caso de nuestros ejemplos, el servidor sshd y las aplicaciones residen en susana y el servidor X y el cliente de ssh residen en cristina.

Configuración del servidor de ssh

Para poder usar ssh como nuestra capa de transporte, necesitamos pedirle específicamente eso al servidor de ssh. En el archivo de configuración /etc/ssh/sshd_config (la ruta puede variar) busquen que exista una línea que diga:

X11Forwarding yes

Si es el caso, entonces está listo. Si no, agrégenla o descoméntenla y reinicien el servicio de sshd.

¿Qué es lo que hace esta opción de configuración? Una vez que esté establecida la conexión de ssh (después de pedirnos el password y/o autenticar nuestra clave pública), el servidor espera que le llegue el cookie del servidor X desde el lado del cliente, y si lo recibe, el servidor de ssh abre un socket en susana (por default en el puerto 6010), coloca el cookie en el .Xauthority de susana y define la variable a DISPLAY=localhost:10.0.

El cliente

Si leyeron el párrafo anterior, se preguntarán cómo se hace para enviar el cookie al servidor de aplicaciones. Simple: existen dos opciones en ssh que permiten hacerlo: -X e -Y. La diferencia entre estas opciones es el nivel de acceso que dan al servidor X local.

  • La opción -X da acceso "limitado" al servidor X. Esto significa que la aplicación que corre en susana solo tendrá acceso a ciertas estructuras de datos del servidor, definibles en /usr/lib/xserverSecurityPolicy (la ruta puede variar, pero consulten los manuales de X, la seccion del módulo X SECURITY)
  • La opción -Y da acceso completo al servidor X, de manera que la aplicación puede ver todas las estructuras de X

Esto significa que usar la opción -X puede hacer que ciertas aplicaciones (que usan versiones antiguas de las bibliotecas de X) den problemas - como cerrarse inesperadamente. Esto suele pasar cuando la aplicación está en una versión de unix diferente a la del servidor X. Personalmente, lo he visto pasar con menos frecuencia, pero aún pueden haber casos. En caso de que ello pase, pueden usar la opción -Y.

Bueno, después de toda esta teoría, lo único que tienen que hacer es:

cristina$ ssh -X acl@susana
/usr/bin/xauth: creating new authority file /home/acl/.Xauthority
susana$ echo $DISPLAY
localhost:6010.0
susana$ xterm

¡Y listo!

X sobre MS-Windows

La ventaja de que X haya sido diseñado con un protocolo abierto sobre tecnologías de red abiertas permite que cualquier sistema con TCP/IP pueda implementar tanto clientes como servidores de X. En teoría, uno podría correr un servidor X como una aplicación de windows y aceptar conexiones de clientes remotos para desplegarlos en la pantalla de windows. Bueno, eso es justamente lo que vamos a hacer.

Primero, necesitamos un cliente de ssh para windows. Uno de mis preferidos es putty (no necesita instalación y la versión portátil ni siquiera necesita escribir en el infame registry). Pero cualquier cliente que soporte X11Forwarding sirve.

Al abrir putty, pueden navegar a la opción Connection -> SSH -> X11. Allí activen la casilla "Enable X11 Forwarding" y abran la conexión al servidor remoto.

En este ejemplo, aún no tengo Xming corriendo y por ello los mensajes de error.

Xming es una implementación libre y gratuita de un servidor X para windows. Al bajárselo y e instalarlo, podrán arrancar el servidor X. Este servidor de X es una aplicación que usa las llamadas de windows para traducir las aplicaciones a píxeles y escucha en la red para recibir clientes de X. Pueden bajarse Xming de sourcefourge.

Una vez arrancado, podrán ejecutar las aplicaciones y mostrarlas sobre windows. En la siguiente captura, me volví loco y corrí montones de cosas en mi servidor y las muestro todas sobre windows.

La sesión completa

También podemos ir más alla y arrancar el proceso que deja listo todo el ambiente de escritorio. Para ello es necesario desactivar la opción de "Hide Root Window" y con ello tendremos la pantalla gris de X lista para mostrar todo lo que venga. Luego arrancamos startkde o gnome-session en el servidor remoto y tendremos el ambiente de escritorio completo corriendo en el servidor X local.

He intentado hacer justamente esto con Xming, pero no lo he logrado (me imagino porque el manejador de ventanas de kde conflictúa con el manejador de ventanas de windows y tal vez por los fonts). En fin, en servidores X normales sí funciona.

Pero hay otra forma de manejar la sesión completa de un servidor de X remoto, y eso lo veremos en la siguiente parte.