ssh
es un ejemplo de tunneling.
Tunneling o redireccionamiento de puertos (port forwarding)
es una técnica que permite redireccionar tráfico TCP inseguro
a través de SSH.
Para establecer una conexión gráfica use la opción -X
.
$ ssh -X loginname@machine1 lhp@nereida:~$ ssh -X orion Linux machine1 2.6.8-2-686 #1 Tue Aug 16 13:22:48 UTC 2005 i686 GNU/Linux $ echo $DISPLAY localhost:10.0
En el sistema de ventanas X un display consiste en un teclado, un ratón
y una pantalla.
Cuando se invoca un cliente X este necesita saber que DISPLAY utilizar.
Un display queda determinado por una cadena de la forma HOST:n.v
, donde:
El hecho de que $DISPLAY
valga localhost:10.0
se traduce en
la instrucción:
'conéctate con TCP al puerto 10+6000 = 6010'.
La aplicación ejecutándose en orion
, por ejemplo xclock
se conectará
al puerto 6010 de localhost (orion). El daemon de ssh en orion esta ya escuchando en
ese puerto y redirige
la salida gráfica en ese puerto através del puerto 22 de orion hacia el cliente.
El mensaje está cifrado. El mensaje cifrado es recibido por el cliente
el cuál lo descifra y lo envía descifrado al servidor X local.
Obsérvese que el puerto 6010 de orion
sólo es accedido desde
orion
. No hay por tanto necesidad de dejar los puertos del servicio X
6000 en adelante abiertos al exterior.
Figura: Redirección de las X via SSH
Comprobemos lo dicho con un ejemplo.
Primero nos conectamos a una máquina solicitando redireccionamiento
de las X y comprobamos donde esta puesto el DISPLAY
:
lusasoft@LusaSoft:~$ ssh -X pp2@europa.deioc.ull.es pp2@europa:~$ env | grep -i displa DISPLAY=localhost:21.0 pp2@europa:~$
Ahora arrancamos una segunda sesión SSH, pero no solicitamos
redirección de las X. Establecemos la variable DISPLAY
al valor que tenemos en la otra sesión y reutilizamos
el servicio de redirección:
lusasoft@LusaSoft:~$ ssh pp2@europa.deioc.ull.es pp2@europa:~$ export DISPLAY=localhost:21.0 pp2@europa:~$ xclock & # Aparece un reloj en nuestro escritorio [1] 5904 pp2@europa:~$ pp2@europa:~$ konsole & # Aparece una consola KDE en el escritorio [2] 5906 pp2@europa:~$ kbuildsycoca running... Reusing existing ksycoca kdecore (KProcess): WARNING: _attachPty() 10
Es posible especificar también el redireccionamiento de las X con la opción ForwardX11 yes en el fichero de configuración.
Si no funciona el tunneling de las X
puede ser debido a la configuración de ssh
.
Habra que comprobar los ficheros de configuración
del cliente ssh_config
y del servicio sshd_config
.
Habitualmente la configuración por defecto desabilita
el redireccionamiento de las X. Para permitirlo
hay que poner:
X11Forwarding yes
y las siguientes líneas en el fichero de configuración del cliente /etc/ssh/ssh_config
:
ForwardAgent yes ForwardX11 yesPor ejemplo:
$ grep X11 /etc/ssh/ssh*fig /etc/ssh/ssh_config:# ForwardX11 no /etc/ssh/ssh_config:# ForwardX11Trusted yes /etc/ssh/sshd_config:X11Forwarding yes /etc/ssh/sshd_config:X11DisplayOffset 10
El servicio ssh
modifica automáticamente la variable de entorno
DISPLAY
a un valor de la forma hostname:n
donde hostname
es el nombre
de la máquina en la que se ejecuta la shell y n
es un entero. El usuario
no debería establecer el valor de esta variable manualmente.
Supongamos que tenemos KDE en la máquina local. Nos conectamos a la máquina remota con redirección de las X:
pp2@nereida:~/pp2bin$ ssh -X -v beowulf
Ahora podemos establecer un escritorio Gnome sin mas que invocarlo en la máquina remota:
casiano@beowulf:~$ gnome-session &
Observe que procesos suyos se están ejecutando en la máquina remota después de cerrado el desktop gráfico:
casiano@beowulf:~$ ps -fA | grep casiano casiano 302 1 0 13:34 ? 00:00:00 xscreensaver -nosplash casiano 900 1 0 13:45 pts/2 00:00:01 /usr/lib/iceape/iceape-bin -browser casiano 953 32648 0 13:48 pts/2 00:00:00 ps -fA casiano 954 32648 0 13:48 pts/2 00:00:00 grep casianoEs posible que tenga que matar alguno:
casiano@beowulf:~$ kill -9 302 debug1: channel 11: FORCE input drain casiano@beowulf:~$ debug1: channel 11: free: x11, nchannels 5
pp2@nereida:~/pp2bin$ ssh -X -v beowulfInicie el escritorio de KDE :
$ startkde¿Que ocurre?
CTRL-ALT-F2
(o cualquier
otra TTY
alternativa). Ahora podemos conmutar entre las terminales
desde ALT-F1
hasta ALT-F6
. Para volver a la sesión
gráfica actual pulsamos ALT-F7
.
ALT-F1
. Introduzca un login y una password.
No tiene por que ser el mismo usuario que tiene en la otra sesión.
$ xinit -- :1 vt12El programa xinit inicia las X. También puede usarse startx, que es un front-end para xinit.
Por defecto xinit
y startx
arrancan las X en el display :0
y a continuación una xterm.
Cuando la xterm
termina se elimina el servicio X.
También suele ser posible terminar las X presionando la combinación Control-Alt-Backspace.
En general, xinit
arranca un servidor X y ejecuta un cierto script.
Lo normal es que este script corra un cierto número de programas y finalmente un gestor
de ventanas.
La sintáxis de xinit
es:
xinit [ [ client ] options ] [ -- [ server ] [ display ] options ]
:1
hace que usemos un display alternativo
al que se está usando (probablemente el :0
).
Si se quieren ejecutar múltiples servicios X en la misma
máquina, cada uno debe tener un número de display distinto.
vt12
es opcional, y asocia la sesión gráfica
con la tecla ALT-F12
en vez de asociarla con la primera
que esté disponible. Si no especificamos esta opción continuaría en F8
, etc.
Si queremos iniciar mas sesiones deberemos especificar DISPLAYs alternativos :2, :3, etc.
CTRL-ALT-F7
y CTRL-ALT-F12
Con una instalación de Cygwin en su máquina Windows (Véase http://www.cygwin.com) arranque una xterm . Haga una conexión con X forwarding a la máquina UNIX:
$ ssh -X user@beowulfAhora puede arrancar un desktop (o cualquier otro programa gráfico) contra la máquina windows sin mas que hacer
$startkdeVéase una captura de pantalla (screenshot) en http://x.cygwin.com/screenshots/cygx-xdmcp-kde3.1-20031224-0010.png.