Abrir una sesión X11 vía VNC

Desde que estoy en Bilbao ha sido muy socorrido que Gnome venga integrado con su propio servidor VNC (vino, accesible vía Sistema > Preferencias > Escritorio remoto). Eso me permite dar soporte a mi madre en sus pequeños problemillas con el PC.

Pero esta característica out of the box tiene limitaciones, como que vino solo permite acceder a una sesión X11 existente (como la que suele tener abierta mi madre), y no crear tus propias sesiones.

Cuando quiero acceder a ciertos datos de mi máquina que dejé en casa, y vía SSH es imposible porque son datos que dependen de una aplicación con interfaz gráfico, con la conexión que tenemos por aquí a Internet es muchas veces inviable traer aunque sea sólo una aplicación con el protocolo de X11. El no poder crear una sesión me impide trabajar con vino en este caso, porque no hay sesión abierta.

Así que voy a explicar cómo lo he solucionado: permitiendo abrir sesiones X11 vía VNC.

VNC (del inglés Virtual Network Computing) es un sistema para poder acceder a un escritorio de forma remota que se desarrolló en los laboratorios de AT&T de Cambridge (antes era el ORL, de Olivetti Research Laboratory).

En VNC se emplea el protocolo RFB, que es aplicable a cualquier sistema de ventanas (no solo X11), y que lo hace universal, ya que su especificación además es abierta.

Digamos que VNC es algo así como el telnet para la administración remota, pero con entorno gráfico, aportando ventajas sobre usar simplemente el protocolo de X11 en red (por ejemplo XDMCP), pudiendo negociar métodos en cada momento para enviar la información (empleando compresión).

Igual ha llamado la atención eso de como el telnet para la administración remota, ¿por qué no he dicho SSH? Pues porque VNC por defecto no es suficientemente seguro.

Aunque el protocolo RFB no manda las contraseñas en claro, el cifrado no es los suficientemente robusto y resulta viable hace un ataque con fuerza bruta (con tiempo y una caña). Por eso se recomienda añadir una capa de cifrado mediante un túnel SSH o usando una VPN, o empleando un servidor VNC que tenga como añadido algún mecanismo de cifrado más potente.

En mi caso he optado por SSH, más que nada porque me va a servir como mecanismo cómodo para llegar a mi máquina desde el servidor de casa sin tener que redirigir un puerto (asumiendo que la red local de casa es segura :D). En realidad una contraseña adecuada (más de 8 caracteres, usando mayúsculas, minúsculas y números), sería suficiente para la mayoría de los usos.

Una vez hecha una pequeña introducción, vamos a realizar la configuración en homeworld, mi máquina de casa. Primero hay que elegir un servidor VNC que nos permita abrir nuevas sesiones.

Este tipo de servidores son en realidad servidores X con la particularidad de no tener un display normal, sino son accesibles vía un cliente VNC. Existen varias opciones libres, destacando RealVNC o TightVNC (derivado del anterior).

Me he decantado por TightVNC:

reidrac@homeworld$ sudo apt-get install tightvncserver

Como no tengo acceso vía X, voy a realizar los cambios a mano. Primero vamos a añadir nuestro nuevo servidor en /etc/gdm/gdm.conf-custom:

[servers]
1=VNC

[server-VNC]
name=VNC
command=/usr/bin/Xvnc -desktop homeworld -geometry 1024x768 -depth 16 -once -localhost -I
handled=true

Reiniciamos GDM, y listo.

Veamos qué parámetros he usado en el servidor VNC:

• -desktop homeworld: Es el nombre que aparecerá para las sesiones VNC.
• -geometry 1024x768: La resolución del escritorio. En casa trabajo con más resolución, pero para acceso remoto será suficiente.
• -depth 16: La profundidad de color. Igual que en el punto anterior, no es necesario 24 bpp.
• -once: Que se ejecute una sola vez. Esto es para que no haya problemas al correr el servidor desde GDM cuando cerremos la sesión.
• -localhost: Solo aceptaremos conexiones locales. Es por seguridad y porque vamos a hacer un tunel SSH.
• -I: Esta opción es importante: ignorará el resto de los argumentos. GDM añade varios argumentos a la orden que indicamos para ejecutar un servidor X. Al principio añadirá el display (:1 en este caso) y no causará problemas, pero además incluirá otros parámetros que no aplican a un servidor VNC y que harán que el programa no arranque. Esta opción está en TightVNC, y es el motivo por el que lo he elegido.

Ahora hacemos la prueba de conectar al servidor, en mi caso empleando xtightvncviewer, que tiene más posibilidades que el vncviewer que viene por defecto con GNOME. Además en mi configuración he suprimido el -localhost porque es una máquina en mi red local y no hay acceso a ella desde fuera si no es con un túnel SSH:

reidrac@vortex:~$ xtightvncviewer -via usuario@blackshell.usebox.net homeworld:1

Si la máquina fuera directamente accesible y empleáramos la opción -localhost, ejecutaríamos:

reidrac@vortex:~$ xtightvncviewer -via usuario@homeworld 127.0.0.1:1

Solo destacar que indicamos el display con el :1 al final de la dirección IP. Nos pedirá nuestra contraseña SSH y ya podremos acceder a la sesión VNC a través del túnel.

Preparados para entrar en casa ;)

Adicionalmente podemos añadir los parámetros -nevershared -dontdisconnect a la ejecución de Xvnc para evitar que alguien se conecte al servicio cuando estamos trabajando, porque compartiría la sesión con nosotros si tener que autentificarse, lo cual es malo. Con la opción -localhost no puede pasar, pero en mi caso, cualquiera en mi red local puede conectarse.

El resultado es excelente, aunque si trabajamos con Feisty en el servidor tendremos problemas con Gnome (o en realidad con cualquier aplicación GTK+). Parece que hay un bug relacionado con una extensión de X.org que GTK+ parece detectar pero en realidad no existe en Xvnc, con lo que en las aplicaciones que usen ese toolkit, el teclado estará mal mapeado :(. Esto no ocurre en Edgy y anteriores.

En Feisty hay una corrección si usamos vnc4server (RealVNC en realidad) con la opción -extension XFIXES, pero ese servidor requiere otro tipo de configuración empleando XDMCP y un superservidor inetd, así que lo he descartado porque TightVNC me parecía más limpio de instalar y configurar.

He actualizado a Gutsy (que es beta, ojo), y el problema persiste, así que estaré atento a ver si aparece un fix que me permita disfrutar al 100% del invento. Parece que la solución pasa por corregir el servidor Xvnc, que sigue siendo la misma versión que en Feisty.