6.4.2.- Utilizar clientes de X remotos

upongamos que tenemos dos ordenadores. Una máquina la llamaremos alfa y la otra beta, alfa es una potente máquina que aloja programas importantes, como un procesador de texto y utilidades para el análisis de datos. En cambio tenemos la otra máquina llamada beta que es mucho menos potente, pero posee un monitor y un teclado. Por lo tanto, es recomendable sentarse y utilizar el ordenador beta y ejecute los programas que se encuentran en alfa. Ambos sistemas utilizan Linux. Seguiremos estos pasos para realizar estas tareas:

Primer paso

maquinas1

Segundo paso

maquina2

Tercer paso

maquina3

Este comando le indica a beta que acepte los datos que provienen de alfa para que sean mostrados en su servidor de X.

Cuarto paso

maquina4

Por ejemplo, debería usar Telnet o Secure Shell (SSH). El resultado sería tener la posibilidad de escribir comandos en una consola de alfa.

Quinto paso

maquina5

Se asume que utilizamos bash, si utilizamos la consola tcsh, el comando sería: setenv DISPLAY beta:0.0. Este comando le indica a alfa que utilice la máquina beta para mostrar los programas de X.

Sexto paso

maquina6

Como ejemplo podríamos escribir ooffice para iniciar OpenOffice.org. Deberíamos ver que el programa se abre en una visualización en la máquina beta recayendo el uso sobre la CPU alfa, también podemos leer los ficheros accesibles en alfa.

Séptimo paso

maquina7

Encriptar conexiones X con SSH

zDIIS5QqQwgpEl protocolo SSH es una herramienta útil de acceso remoto. Frecuentemente conocido como un protocolo en modo texto, SSH también posee la capacidad de realizar conexiones de red seguras (tunneling); es decir, transporta otro protocolo a través de su propia conexión encriptada. Siendo muy útil esta característica para controlar el acceso remoto a X. Podemos seguir los pasos que describimos anteriormente, pero omitiendo los pasos Tercero y Quinto y el comando xhost del paso Séptimo. Esto simplifica el acceso y añade ventajas de la encriptación SSH, que X no proporciona. Por otra parte puede que la encriptación de SSH ralentice el acceso a X, aunque si activa las funcionalidades de compresión de SSH puede que reduzca este problema. En general, transportar X a través de SSH es el método preferido de acceso remoto a X, particularmente si ninguna de las redes son seguras. Este método requiere una configuración de ciertas opciones. Concretamente, debe pasar la opción -X al programa cliente de ssh o definir la opción ForwardX11 como yes en /etc/ssh_config en el sistema cliente. También  debe definir la opción X11Forwarding como yes en el fichero /etc/sshd_config del sistema del servidor SSH. Estas opciones activan la funcionalidad de reenvío de X de SSH y son fundamentales para que ésta funcione.

Habrá veces en las que se pueda saltar algunos de estos casos. Por ejemplo, dependiendo de como está configurado, SSH podrá reenviar conexiones X, lo que significa que SSH interceptará los intentos de mostrar la información de X y le pasará estas peticiones al sistema que inició la conexión. Cuando esto ocurra, podremos saltarnos los pasos Tercero y Quinto, así como el comando xhost del paso Séptimo.

Como medida de seguridad adicional, muchas distribuciones Linux actuales configuran X para que ignore las conexiones de red reales. Si su distribución está configurada de esta manera, los pasos anteriores no funcionarán; cuando intentemos iniciar un programa X desde el sistema remoto, obtendrá un mensaje de error. Para solucionar este problema, deberá realizar un cambio adicional, dependiendo de como se inicie X:

  • GDM.- En las versiones anteriores de GDM, revise, el fichero de configuración de GDM (que suele ser /etc/X11/gdm/gdm.conf): busque la línea DisallowTCP=true y cámbiela por DisallowTCP=false. en las versiones más recientes de GDM, edite /etc/gdm/gdm.schemas y busque la línea que contiene <key>security/DisallowTCP</key> cambie la clave (key) que figura un par de líneas por debajo de ésta de true a false.
  • KDM o XDM.- Estos servidores XDMCP se basan en los parámetros del fichero Xservers (en /etc/X11/xdm para XDM; en esta ubicación o alguna otra bastante variable para KDM). Busque la línea que comienza por :0. Esta línea contiene la cadena -nolisten tcp, elimine la cadena de la línea. Esto eliminará la opción que hace que X ignore las conexiones de red convencionales de X.
  • Configuración especial de OpenSUSE.- En OpenSUSE, editar /etc/sysconfig/displaymanager en la opción DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN ponemos yes.
  • X iniciado desde un acceso de tipo texto.-  Cuando empleamos un acceso remoto en modo texto escribiendo startx para iniciar X, puede que tenga que modificar el propio script startx, que se suele encontrar en /usr/bin. Busque en ésta cadena -nolisten tcp. Posiblemente esta cadena aparezca en la asignación de una variable (como defaultserverargs) o, posiblemente, en una llamada directa al programa del servidor de X. Elimine la opción -nolisten tcp de esta asignación o llamada.

Una vez que hemos realizado estos cambios, tendrá que reiniciar X como ya se describió anteriormente en relación a la ejecución de un servidor XDMCP. Después de esto debería responder a las peticiones de acceso remoto.

tux_maestro_derAviso.- Los mantenedores de las distribuciones desactivan la capacidad de X de responder  a peticiones remotas por un el motivo de que podría colarse algún intruso y ejecutar algún bug o configuración errónea para engañar a los usuarios mostrando mensajes falsos por la pantalla. Por tanto, debería desactivar esta protección sólo si está seguro de que es necesario hacerlo. Puede que podamos utilizar una conexión SSH sin desactivar esta protección. SSH posee también otras ventajas.

 realvncTenemos otra opción para ejecutar programas de X y es el de utilizar el sistema VNC (Virtual Network Computing), cuyo sitio es www.realvnc.com. VNC ejecuta un servidor X especial en el ordenador que se va a utilizar a distancia, mientras que el ordenador donde estamos se ejecuta un cliente VNC. Este cliente se utiliza para contactar directamente con el servidor. VNC también es un protocolo independiente de la plataforma donde se puede controlar un sistema Windows o Mac OS desde Linux utilizando VNC, algo que no X no es posible (hay servidores de X disponible para Windows o Mac OS, que le permiten controlar un sistema Linux desde estos SO).

Anuncios