Publica tu how-to

Dinos como hacer lo que sabes hacer, mándanos un email a wdonet@gmail.com y lo publicamos (dos días máximo) o si te interesa unirte al equipo de redactores, también háznoslo saber por correo.

Servidor VNC para sesiones de escritorios remotos

Introducción
VNC (Virtual Network Computer) es el software a través del cual se puede iniciar sesión en escritorio remoto con GNU/Linux.

Otra opción es el RDP de Windows, sin embargo aquí explicaremos únicamente como configurar el servidor para el caso de VNC.

Lo primero que hay que saber es que VNC funciona para controlar escritorios remotos que utilizan el servidor gráfico X-Window , el default de GNU/Linux hasta ahora. Sin entrar en detalles de cómo funciona X-Window, basta saber que en este tutorial explicaremos dos opciones:

  1. controlar el escritorio X real que se tenga en el escritorio remoto
  2. controlar un escritorio X virtual que se crea a demanda en dicho escritorio remoto
Ambas opciones tienen posibilidades de aplicación.



Por ejemplo, si lo que deseamos es que otras personas vean mi escritorio mientras yo lo manipulo, puedo levantar VNC usando la opción 1 y permitiendo que los demás se conecten sólo en escucha (sin posibilidad de intervenir en mi sesión). Y de esta manera se pueden impartir cursos o hacer demostraciones en vivo.

Si lo que deseamos es acceder a sesión remota del escritorio para poder acceder como si se tratara de estar sentado físicamente frente a la máquina, pero sin estarlo, y que no importe (o no se requiera) manipular directametne la terminal real de X, sino sólo iniciar sesión, puedo levantar VNC usando la opción 2.


Cabe entonces mencionar que en X se tiene siempre asociada una 'pantalla' (display) real con la terminal física. Normalmente se le asigna el número 0 como identificador. A partir de ahí, el programa Xserver permite levantar nuevas 'pantallas' virtuales (displays) no relacionadas con la terminal física. Es decir que si usamos la pantalla #1, al no ser la física, podemos acceder a ella a través de VNC, pero en la pantalla física no se verá nada (pues esta es la 0, no la 1).

Requisitos previos
Los programas en cuestión que necesitamos instalar son los siguientes:
  • opción 1: x11vnc en el servidor
  • opción 2: TightVNC , RealVNC, UltraVNC o cualquier otro que permita VNC en el servidor
  • clientes: cualquier visor de VNC, como krdc, realvnc vncviewer, etc. No entraremos en detalle sobre el uso de los clientes, ya que se trata de algo muy intuitivo, bastará conectarse al servidor VNC una vez que esté levantado en el puerto que se haya configurado para lo mismo. Cabe anotar que los clientes pueden correr en cualquier plataforma independientemente de que el servidor sea GNU/Linux u otro. Por ejemplo, se puede iniciar sesión remota con un cliente en Windows, a pesar de que el servidor sea GNU/Linux. Otra anotación interesante sobre los clientes es que algunos servidores de VNC (por ejemplo TightVNC) permiten levantar el servidor a través de una interfaz en Java para que el escritorio remoto pueda ser accedido a través de un navegador web con soporte para Java, utilizando un applet específico para lo mismo.
  • configurar XDMCP en el escritorio remoto para permitir el incio de sesión.
También hay que asegurarse de tener instalado en el servidor el programa Xserver, y de preferencia el superservidor xinetd, que permitirá conectarse a pantallas virtuales sin consumir recursos del servidor cuando no se esté utilizando VNC y a la vez permitir a más de una persona conectarse a su propia sesión con VNC sin que el servidor bloquee puertos ni nada por el estilo.



Inicio de sesión remoto

XDMCP es un protocolo que, en resumen, permite el incio de sesión remoto en terminales X de cualquier índole.

Si no configuramos XDMCP, entonces solamente podremos acceder a pantallas que ya tengan la sesión iniciada. Puesto que esto sólo es posible en pantallas físicas, nos veríamos restringidos a la opción #1, sin posibilidad de utilizar la pantalla de inicio de sesión de la pantalla que quisiéramos controlar, por lo que sólo sesiones previamente iniciadas podrían ser controladas. Esto no es ni práctico, ni mucho menos seguro, lo recomendable es que podamos iniciar sesión en modo gráfico en el escritorio remoto a partir de un prompt de nombre de usuario y password por validar.

XDMCP se configura de manera diferente, dependiendo el manejador de pantalla que estemos utilizando. Físicamente, sin importar el tipo de manejador de escritorio que estemos utilizando (GNOME, KDE, XFCE, etc.), se utiliza un manejador de pantalla para poder iniciar sesión en nuestro escritorio remoto, incluso cuando estamos sentados físicamente frente a él. Las opciones más comunes son: gdm, kdm y xdm. (Normlamente GNOME utiliza gdm, pero podría utilizar otro; KDE utiliza kdm pero podría ser otro, y así...)

xdm

Debe abrirse el archivo xdm-config y comentarse la línea con el texto
DisplayManager.requestPort :0
insertando un ! al inicio.

El usuario 'nobody' debería de tener asociada una terminal shell válida para poder iniciar sesión, por lo que hay que ejecutar:
usermod -s /bin/bash nobody

gdm
Debe ejecutarse gdmconfig, encontrar la pestaña llamada 'XDMCP' y habilitar esta opción.

En escritorios como XFCE, que a veces usan también gdm, la opción se encuentra, dentro del menú 'Configuración', en la pantalla 'Ventana de entrada', en la pestaña 'Remota' hasta abajo se encuentra el botón 'Configurar XDMCP' (obviamente hay que empezar por habilitar la pestaña Remota en los permisos de inicio de sesión dentro de esta misma pantalla).


kdm
Debe editarse el archivo kdmrc y habilitar XDMCP en el puerto 177:
[Xdmcp]
Enable=true
Willing=/etc/X11/xdm/Xwilling
Xaccess=/etc/X11/xdm/Xaccess
Port=177

seguridad
En caso de soportarlo, lo recomendable también es configurar quiénes pueden acceder a sesión. Esta configuración depende completamente del manejador de pantalla que se tenga pero no entraremos en detalle en este caso.

Más información aquí.



Opción 1 (x11vnc , control directo de la terminal física remota)
Como dijimos, se trata de manipular remotamente la pantalla 0, la cual X asocia por default a la terminal física de la máquina que llamaremos en adelante 'escritorio remoto'.

En 'escritorio remoto' hay que instalar entonces x11vnc y Xserver.

Hecho eso, se puede lanzar una línea como la siguiente:
x11vnc

Lo cual nos brindará información adicional sobre los parámetros que deberíamos de lanzar para autenticar nuestra sesión, entre otros.

Yo uso normalmente la siguiente línea:
x11vnc -auth /var/lib/gdm/:0.Xauth -display :0 -shared -forever -ncache -rfbport 5901 -rfbauth ./.vnc/passwd_x11vnc

En donde el parámetro -auth asocia el archivo :0.Xauth (que hay que localizar en el 'escritorio remoto' para cada caso particular) y de esa manera si mi escritorio remoto se quedó en la pantalla de login, poder hacer uso de la autenticación y así poder iniciar sesión. Si no se usa este parámetro, se tendría que tener la pantalla 0 ya dentro de sesión en el escritorio remoto para poder hacer uso del acceso remoto.

El parámetro -forever permite escuchar constantemente conexiones aunque estas se terminen, siempre y cuando no se cierre la sesión gráfica en 0

El parámetro -rfbport indica el número de puerto en que estará escuchando el 'escritorio remoto' para aceptar conexiones. 5901 es el puerto por default para VNC. Por cierto, no hay que olvidar abrir este puerto en el firewall del escritorio remoto.

El parámetro -rfbauth apunta a un archvio en el que previamente almacené un password para autenticar el acceso a mi servidor y así evitar que cualquiera que conozca la dirección IP de mi escritorio remoto se pueda conectar a mi terminal gráfica física 0 y por lo tanto ver o intervenir en mis sesiones directamente (este riesgo es MUY REAL, hay que generar el password siempre). Para generar el archivo del password, x11vnc debe ejecutarse con el parámetro -storepassword, por ejemplo:
x11vnc -storepassword /path/al/archivo_de_password
Aquí no entraremos en detalle para levantar x11vnc usando xinetd, pero el sitio oficial de x11vnc da más información. Además, traspolando un poco la información que daremos para la opción #2, se puede lograr levantar un servidor así.

Antes de concluir con x11vnc, hay que aclarar también que para poder inciar sesión remota también es necesario configurar el protocolo XDMCP como se explicó anteriormente...



Opción 2 (vnc, control de pantallas virtuales remotas)

En este caso se manipularán pantallas virtuales no directamente relacionadas con la terminal física del escritorio remoto. La idea será que dichas pantallas se creen a demanda también.

En el escritorio remoto habrá que tener instalado tanto el software que se usará como servidor VNC (tightvnc, ultravnc, realvnc, etc.) y Xserver.

Hecho eso se puede ejecutar la siguiente línea de comandos:

vncserver -query localhost -once -geometry 1024x768 -depth 16 :1

Con lo que se tendrá un servidor VNC en la pantalla virtual #1, y si esta no estuviera disponible, buscaría en la 2, y así sucesivamente.

El parámetro -once indica que sólo permitirá el inicio de sesión una vez, luego de terminar la cual cerrará el servidor. Esta opción es más útil aún usando un superservidor como se explica más adelante.

El parámetro -geometry 1024x768 define la resolución que tendrá la sesión en el escritorio remoto.

El parámetro -depth 16 indica la profundidad de color a obtener en la sesión remota, en este caso a 16 colores.

El parámetro :1 indica el número de pantalla virtual que se desea utilizar.

El parámetro -query localhost indica que se desea iniciar sesión en el escritorio remoto a través de XDMCP.

Para que se autentique a los usuarios, es necesario crear previamente el archivo de passwords con el programa vncpasswd. Por default, vncserver busca en $HOME/.vnc/passwd


Superservidor xinetd

Sin embargo, levantar manualmente un servidor de pantallas virtuales VNC no es la forma más óptima, ya que se tienen estos inconvenientes:
  • hay que levantar nuevamente el servidor cada vez que se termine de usar
  • solamente podrá entrar a sesión por VNC una persona, y si se tiene más de un usuario que pudiera iniciar sesión en el escritorio remoto (cada uno a su propia sesión), no se les permitiría.
  • además si no se está utilizando el servicio VNC en un momento dado, aún así se está consumiendo memoria en el servidor, con el programa a la escucha de posibles conexiones.
La solución implica levantar algo conocido como un superservidor, de los cuales xinetd es el más popular en GNU/Linux. El superservidor permite levantar a demanda instancias de los servidores configurados en él. Esto trae ventajas de menor consumo de memoria, además de permitir levantar instancias múltiples del servidor escuchando un sólo puerto (que atiende el superservidor). Y en cuanto se termine de usar el servidor en cuestión, el superservidor sigue atento para nuevas solicitudes. Un superservidor es útil para servidores que no están en constante uso o que no requieren de alta disponibilidad, podría ser (dependiendo las circunstancias, claro): telnet, ftp, o en nuestro caso vnc.

Una vez instalado xinetd, lo único que debe hacerse es agregar la configuración adecuada para utilizar VNC a través del mismo. Esta configuración se puede escribir en un archivo exclusivo para VNC, pero debe asegurarse de guardarse en donde xinetd lo lea, por lo regular en /etc/xinetd.d

El siguiente es un ejemplo de un servidor VNC levantado a través de xinetd:
service vnc
{
protocol = tcp
socket_type = stream
wait = no
user = user_name
server = /usr/bin/Xvnc
server_args = -inetd -query localhost -once -geometry 1024x768 -depth 16 -rfbauth=/home/user_name/.vnc/passwd
disable = no
}
Antes de utilizarlo, explicaré algunos detalles:

-El servidor que se mandó llamar utiliza el programa 'Xvnc', en vez de 'vncserver'. Leyendo la página del manual de vncserver (man vncserver), se puede constatar que en realidad vncserver es un wrapper que manda llamar en el fondo a Xvnc, por lo que este último programa será el indicado para llamar en las instancias que genere el superservidor.

-Los argumentos incluyen el parámetro -inetd que es necesario para que el servidor VNC sepa que fue mandado llamar desde un superservidor.

-Se incluye el parámetro -rfbauth=/path/passwd , el cual es la ruta al archivo de password a utilizar.

-El nombre de usuario 'user_name' se utilizó en este caso para que el servidor se ejecute a nombre de este usuario. Normalmente se utiliza el usuario 'nobody', pero este debe de tener permisos de lectura al archivo de password, por lo que otra opción implica ejecutar el servidor como otro usuario, con acceso al archivo de password en una ruta particular.

-Si se utiliza TightVNC, las opciones de configuracion no deben incluir el caracter '=', sino que hay que sustituirlos por espacios


Una vez configurado el servicio, hay que reiniciar xinetd:
/etc/init.d/xinetd restart

(o cualquiera que sea la manera de hacerlo en tu distribución en particular).

No hay que olvidar abrir el puerto 5901 (que es el default de VNC, en realidad es el puerto 5900 + N, donde N será el número de pantalla virtual que se utilice) para escuchar las peticiones a conectarse.

Igualmente no olvidar que aunque muchos usuarios se puedan conectar al servidor VNC, sólo una persona a la vez podrá entrar a una sesión en particular. Si hay más de una sesión disponible en el servidor, cada una podrá ser iniciada una vez, pero no pueden entrar a sesión más de una vez por nombre de usuario.

En este link, se da más información y la posibilidad de levantar más de un servidor con xinetd para escuchar en distintos puertos, para tener la posibilidad de conectarse con distintas resoluciones al mismo servidor VNC.

Algunos servidores VNC (como Tight VNC) permiten conectarse también vía http en un navegador web, utilizando un applet de Java. Hay que consultar la documentación de cada caso particular para poder lograr esto. De entrada, lo que normalmente se hace es utilizar el puerto 5800 + N para obtener esta conexión.

No hay comentarios:

Publicar un comentario

Que opinas sobre esta publicación?