Acceso remoto con SSH

Muchas veces es necesario acceder remotamente a un sistema GNU/Linux para efectuar tareas de diversa índole, como mantenimiento, reconfigurar servicios, buscar archivos, etc. En esta tarea juega un papel vital el uso de SSH (secure shell) que permite acceder al sistema remoto usando una conexión cifrada (encriptada), dándonos acceso a una línea de comandos del sistema remoto. Pero hay ocasiones en que esto no es suficiente. Hay veces en las que es necesario operar con el sistema remoto más allá de la línea de comandos. Es ahí donde aparece la necesidad de escritorios remotos, de ejecución remota de programas gráficos y la necesidad de cifrar esas conexiones. Este apunte está dirigido a lograr esto de una manera que se pretende clara y concisa.

Parte 1: SSH. Lo básico

Secure Shell (ssh), al igual que telnet se utiliza para gestionar el login de acceso a un sistema remoto. Pero a diferencia de telnet, ssh establece una conexión cifrada con el sistema remoto, además de proporcionar otras posibilidades.

Los programas SSH se suministran normalmente en dos paquetes llamados generalmente openssh-server y openssh-client. El primero de ellos debe estar instalado necesariamente en la máquina remota a la que se quiere acceder, mientras que el segundo debe estarlo en la máquina cliente (la mayoría de las distribuciones GNU/Linux lo instalan por omisión). Del lado del servidor, el firewall debe aceptar conexiones entrantes al puerto configurado para SSH. El puerto por omisión es el 22, pero es posible cambiarlo por cualquier otro que el administrador considere conveniente.

Para establecer la conexión, se imparte el comando de la siguiente manera:

ssh usuario@pcremota -p puertor

Donde usuario es un usuario que tengamos en pcremota, pcremota es la IP o el nombre de la PC a la que queremos conectarnos y puerto es el puerto que escucha el demonio de ssh, por defecto es el 22 pero puese ser cambiado, en caso de que sea el 22 no hace falta agregar el parametro -p. Tambien es posible conectarse utilizando el comando:

ssh pcremota -l usuario -p puerto

Si los parámetros suministrados son válidos, el sistema remoto pedirá la contraseña de usuarior. Por ejemplo:

Code:
[vampird@sharwyn]:~$ ssh usuario@pcremota
The authenticity of host 'pcremota (xxx.xxx.xxx.xxx)' can't be established.
RSA key fingerprint is be:0d:c4:b2:cc:ce:ef:0c:d4:ab:98:11:d1:8e:58:54.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pcremota' (RSA) to the list of known hosts.
usuario@pcremota's password:

el mensaje anterior saldra unicamente la primer vez que intentemos conectarnos a pcremota, para las siguientes solo pedira la contraseña

Code:
[vampird@sharwyn]:~$ ssh usuario@pcremota
usuario@pcremota's password:

Si la contraseña es correcta, obtendremos el prompt de la línea de comandos del sistema remoto.

En caso de que utilicemos ssh para conectar a varias máquinas con distintos usuarios y puertos, podemos facilitarnos la tarea de recordar cada uno de ellos utilizando un archivo de nombre ~/.ssh/config

Por cada servidor al que deseamos conectar creamos una entrada como sigue:

Code:
Host hostname 
   Hostname     hostname.dominio.remoto
   User         username
   Port         210

De este modo, para conectar con cada servidor solo tenemos que poner:

Code:
[vampird@sharwyn]:~$ ssh hostname

Parte 2: SSH. Redireccionamiento de X

Con el comando ssh del apartado anterior lograremos una “terminal” en modo texto del sistema remoto. Pero muchas veces es necesario ejecutar alguna aplicación gráfica residente en el sistema remoto. Por omisión, si en la terminal del sistema remoto se ejecuta una aplicación gráfica (como konqueror) ésta buscará un servidor X para conectarse, lo que no encontrará por ser nuestra conexión una terminal de texto.

Muchas órdenes aceptan como parámetro la dirección IP de una máquina en la que corre un servidor X. Por ejemplo,

Code:
[vampird@sharwyn]:~$ xterm -display xxx.xxx.xxx.xxx:0

hará que xterm se visualice en el servidor X :0 de la máquina xxx.xxx.xxx.xxx El problema de esta solución es que los datos entre la máquina remota y la máquina xxx.xxx.xxx.xxx viajarán sin encriptar por la red, pudiendo ser monitoreada y examinada en busca de contraseñas, etc. Además supone que la máquina xxx.xxx.xxx.xxx acepte conexiones externas a su servidor X, cosa no recomendable por razones de seguridad.

Para sobrellevar este problema, se puede recurrir al “redireccionamiento de X” mediante SSH, que crea un servidor X virtual en la máquina remota conectado con el servidor X de la máquina local mediante un túnel cifrado.

Para lograrlo es necesario configurar el servidor SSH remoto para permitir el redireccionamiento, editando el archivo /etc/ssh/sshd_config y asignando el valor yes a la opción X11Forwarding.

De esta manera, la orden sería

Code:
[vampird@sharwyn]:~$ ssh -p puertor -X usuarior@pcremota

o

Code:
[vampird@sharwyn]:~$ ssh -p puertor -X -l usuarior pcremota

Tras suministrar la contraseña del usuario usuarior de la máquina remota, obtendremos una línea de órdenes de la máquina remota, pero con un servidor X tunelizado mediante SSH hacia nuestra máquina local. Todo programa o comando cuya salida necesite de un servidor X será tunelizado hasta el servidor X de la máquina local. Ejemplos típicos son el uso de dolphin, semonkey, yast2, etc. que se mostrarán en la pantalla de la máquina local.

Parte 3: SSH. Túneles

A pesar de la utilidad mencionada en los dos apartados anteriores, la funcionalidad de SSH no termina allí, sino que nos brinda la posibilidad de crear túneles cifrados entre dos computadoras.

La orden que se utiliza para la creación de estos túneles es:

ssh -N -p puertor -L plocal:servidorremoto:premoto -l usuarior pcremota

La opcion -N indica que no se debe iniciar una terminal tras la conexión y la opcion -L suministra los parámetros para el túnel, plocal es el puerto en la máquina local encaminado al puerto del servidorremoto, servidorremoto es la dirección de la máquina que corre el servicio a contactar, desde el punto de vista de la máquina que corre el servidor sshd, premoto es el puerto del servicio que se desea contactar en la máquina servidorremoto

Para ejemplificar, tomemos los dos casos siguientes:

Caso 1:

Necesitamos acceder a un servicio de la máquina remota y este servicio no está configurado para prestarse sobre una conexión cifrada o simplemente está configurado para atender peticiones locales solamente. Un ejemplo de esto es el servidor de bases de datos MySQL que normalmente atiende conexiones que se gestionan desde la propia computadora, rechazando a las procedentes de red.

Muchas veces es necesario conectarse al servidor MySQL desde otra máquina de la red o de Intenet con algún programa de administración. Para lograrlo habría que configurar a MySQL para que acepte conexiones de red (sin cifrar) y configurar el firewall para aceptar conexiones entrantes al puerto de MySQL, dejándolo expuesto a posibles ataques.

En este caso, la máquina remota ejecuta tanto el servidor SSH como el servidor MySQL. Según esto, la orden adecuada para la creación el túnel es:

Code:
[vampird@sharwyn]:~$ ssh -N -L 13306:localhost:3306 usuario@servidor.midominio.algo

A partir de este momento, se puede usar el programa de administración de bases de datos apuntando al puerto 13306 de la máquina local (localhost o 127.0.0.1) para acceder al servidor remoto.

Si en vez de un servidor MySQL estuviéramos haciendo referencia a un servidor Apache corriendo en la máquina remota, la orden a utilizarse sería:

Code:
[vampird@sharwyn]:~$ ssh -N -L 10080:localhost:80 usuario@servidor.midominio.algo

De esta manera, un navegador apuntado a la dirección http://localhost:10080/ en nuestra máquina local accedería al servidor Apache de la máquina remota a través de un túnel SSH.

Caso 2:

El servicio a contactar está corriendo en una computadora de una red interna protegida por un firewall y este firewall tiene corriendo un servidor SSH.

Supongamos que la red internet protegida por el firewall/servidor SSH tiene direcciones del tipo 192.169.10.x y que el servidor MySQL se encuentra en la máquina 192.168.10.21

La orden a impartir es:

Code:
[vampird@sharwyn]:~$ ssh -N -L 13306:192.168.10.21:3306 usuario@servidor.midominio.algo

Entonces, un gestor de bases de datos que apunte al puerto 13306 de la máquina local, accedería al servidor MySQL ejecutándose en la máquina 192.168.10.21 de la red interna conectada a la pc remota.

De igual forma, si habláramos de un servidor Apache, la orden sería:

Code:
[vampird@sharwyn]:~$ ssh -N -L 10080:192.168.10.21:80 usuario@servidor.midominio.algo

y en nuestra máquina local, un navegador apuntando a la dirección http://localhost:10080/ accedería al servidor Apache que corre en la máquina 192.168.10.21 de la red interna conectada a la pc remota.

Notas:

  1. La orden para crear túneles solicita la contraseña del usuario empleado para conectarse al servidor SSH. Una vez validado el acceso NO devuelve el prompt de la línea de comandos. Para interrumpir el túnel debe pulsarse Control+C. Véase la Parte 5 para más información.
  2. El sistema local no permitirá que se redireccionen puertos locales inferiores a 1000 sin contar con privilegios de root. Es decir, un usuario común no podrá redireccionar el puerto local 80 al puerto remoto 80. Sólo root puede hacerlo.

Parte 4: VNC vía túnel SSH

Muchas veces la posibilidad de ejecutar programas gráficos mediante el redireccionamiento de X resulta insuficiente y se requiere acceder a un escritorio remoto completo. La solución radica en instalar un servidor VNC en la máquina remota y acceder desde la máquina local con el programa cliente adecuado. En mi caso particular utilizo tightvncserver para el servidor y krdc para el cliente.

En la máquina remota

Una vez instalado tightvncserver en la máquina remota se debe ejecutar (como usuario no privilegiado) la orden:

Code:
[vampird@sharwyn]:~$ vncserver

You will require a password to access your desktops.

Password: 
Verify:   
Would you like to enter a view-only password (y/n)? n

New 'X' desktop is sharwyn.celestialbeing:1

Creating default startup script /home/vampird/.vnc/xstartup
Starting applications specified in /home/vampird/.vnc/xstartup
Log file is /home/vampird/.vnc/sharwyn.celestialbeing:1.log

[vampird@sharwyn]:~$

Se solicitará una contraseña de acceso y otra para “modo observar”. Inmediatamente se crea un nuevo servidor X y se le asigna el número correspondiente, por ejemplo: 1

En la máquina local

Se ejecuta krdc desde una terminal o con “Ejecutar comando” de KDE (Alt+F2) con los siguientes parámetros:

krdc pcremota:n

Donde pcremota es la computadora que se encuentra ejecutando el servidor VNC y n el identificador del servidor X lanzado por el servidor VNC

por ejemplo,

krdc servidor.midominio.algo:1

o

krdc xxx.xxx.xxx.xxx:1

Se solicitará la contraseña definida al ejecutar el servidor VNC y se mostrará en nuestro escritorio el escritorio de la máquina remota.

Esta forma de conexión presenta dos problemas destacables:

  1. La conexión VNC no es cifrada.
  2. En el firewall se necesita abrir el puerto del servidor X creado por el servidor VNC para que acepte conexiones externas.

Ambos puntos representan obvios riesgos de seguridad ya que la contraseña para la conexión viaja por la red sin encriptar y, además, se deja expuesto el servidor X creado a ataques desde la red.

Basándonos en lo que vimos en este apunte, la solución es crear un túnel SSH para la conexión VNC y así disfrutar un escritorio remoto sobre una conexión segura.

Suponiendo que la máquina remota ejecuta tanto el servidor SSH como el servidor VNC, la orden a utilizar es:

Code:
[vampird@sharwyn]:~$ ssh -N -L plocal:pcremota:premoto pcremota

premoto es el puerto que atiende el servidor X a contactar, creado por el servidor VNC. Los valores posibles son:

5901 para el servidor :1

5902 para el servidor :2

5903 para el servidor :3

etc.

Por ejemplo, la orden

Code:
[vampird@sharwyn]:~$ ssh -N -L 15091:servidor.midominio.algo:5901 servidor.midominio.algo

permitirá contactar con el servidor X :1 corriendo en la máquina servidor.midominio.algo y escuchando el puerto 5901.

Sin túnel, la orden para contactar con el escritorio remoto es

krdc servidor.midominio.algo:1

con túnel, la orden se convierte en

krdc localhost:15901

Para finalizar el escritorio remoto debe cerrarse la sesión del escritorio remoto normalmente y luego dar la siguiente orden en el servidor:

vncserver -kill :n

donde :n es el número de servidor X creado por el servidor VNC. Por ejemplo:

Code:
[vampird@sharwyn]:~$ vncserver -kill :1 
Killing Xvnc process ID 6958
[vampird@sharwyn]:~$

Parte 5. SSH. Opciones adicionales

En todos los casos, el uso del comando ssh supone la solicitud de la contraseña correspondiente a un usuario definido en la máquina remota.

El empleo de contraseñas supone la intervención del operador y también impide que las órdenes se puedan impartir sin recurrir a un modo interactivo.

Para subsanar este “inconveniente” es posible definir una relación de confianza entre el usuario de la máquina local y el usuario de la máquina remota, de manera que no sea necesario suministrar una contraseña.

Para hacerlo recurrimos a otros programas incluidos en el software openssh-client. Primero generaremos un par de claves (pública y privada) y luego enviaremos la clave pública a la máquina remota.

Para generar el par de claves seguimos las instrucciones del post Acceso a maquinas remotas via ssh sin contraseña

=-=-=-=-=
Powered by Blogilo

Anuncios

Etiquetas: ,

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s


A %d blogueros les gusta esto: