Acceso remoto con SSH Autor: Walter Omar Autalán woautalan@ucssi.com.ar Santiago SLUG – Santiago del Estero – República Argentina http://santiago-slug.usla.org.ar ODISEA SL – Santiago del Estero – República Argentina http://www.odiseasl.com.ar Versión 1.0 14-05-2006 Se permite la reproducción total o parcial, siempre que se cite al autor original. Publicado bajo la licencia GNU Free Documentation License (GFDL). http://www.gnu.org/licenses/fdl.html
Índice 1. Destinado a 2. Situación. La necesidad 3. Requerimientos 4. Parte 1: SSH. Lo básico 5. Parte 2: SSH. Redireccionamiento de X 6. Parte 3: SSH. Túneles 1. Caso 1 2. Caso 2 7. Parte 4: VNC vía túnel SSH 8. Parte 5. SSH. Opciones adicionales
Destinado a Usuarios intermedios y avanzados. Por esta razón se obvian: 1. Los pasos para la instalación o descarga, compilación e instalación de los paquetes necesarios 2. Cómo verificar, abrir o cerrar puertos en un firewall 3. Cómo editar un archivo de configuración 4. Etc. [ índice ]
Situación. La necesidad 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.
Requerimientos 1. 2. 3. 4. 5. 6.
Sistema remoto y local corriendo GNU/Linux Servidor SSH en el sistema remoto Cliente SSH en el sistema local Servidor VNC en el sistema remoto Cliente VNC en el sistema local Un enlace de red entre ambos sistemas, ya sea por red local o por Internet
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 opensshserver 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 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 -l nusuarior -p puertor maquinaremota Opción
Descripción
-l nusuarior
es el usuario autorizado para conectarse al servidor sshd remoto
-p puertor
es el puerto que escucha el servidor SSH de la máquina remota (normalmente es el puerto 22)
maquinaremota
es la dirección IP o un nombre válido convertible a dirección IP mediante el uso de resolución de nombres (DNS)
También es válido dar la orden de esta otra manera: $ ssh -p puertor nusuarior@maquinaremota Si los parámetros suministrados son válidos, el sistema remoto pedirá la contraseña de nusuarior. Por ejemplo: $ ssh -l omar -p 22 servidor.midominio.com.ar omar@servidor.midominio.com.ar's password: $ ssh -l omar -p 22 200.100.122.201 omar@200.117.132.217'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 utilizar el fichero .ssh/config.
Por cada servidor al que deseamos conectar creamos una entrada como sigue: Host hostname Hostname User Port
dominio.remoto.com username 210
De este modo, para conectar con cada servidor solo tenemos que poner: $ 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, $ xterm -display 201.110.115.21:0 hará que xterm se visualice en el servidor X :0 de la máquina 201.110.115.21 El problema de esta solución es que los datos entre la máquina remota y la máquina 201.110.115.21 viajarán “limpios” (sin encriptar) por la red, pudiendo ser monitoreada y examinada en busca de contraseñas, etc. Además supone que la máquina 201.110.115.21 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 $ ssh -p puertor -X nusuarior@maquinaremota o $ ssh -p puertor -X -l nusuarior maquinaremota Tras suministrar la contraseña del usuario nusuarior 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 konqueror, xterm, synaptic, 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 nusuarior maquinaremota Opción
Descripción
-p puertor
es el puerto al que escucha el demonio sshd de la máquina remota maquinaremota
-N
indica que no se debe iniciar una terminal tras la conexión
-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 (maquinaremota)
premoto
es el puerto del servicio que se desea contactar en la máquina servidorremoto
-l nusuarior
es el usuario autorizado para conectarse al servidor sshd
maquinaremota
es el servidor ssh que hace de puente entre la máquina local y el servidor 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: $ ssh -N -p 22 -L 13306:localhost:3306 -l omar servidor.midominio.com.ar Opción
Descripción
-p 22
es el puerto al que escucha el demonio sshd de servidor.midominio.com.ar
-N
indica que no se debe iniciar una terminal tras la conexión
-L
suministra los parámetros para el túnel
13306
es el puerto en la máquina local encaminado al servidor MySQL
es la dirección de la máquina a contactar desde el punto de vista del servidor sshd y localhost como el servidor MySQL está ejecutándose en el propio servidor.dominio.com.ar, se usa localhost para autoreferirse 3306
es el puerto que atiende el servidor MySQL
-l omar
es el usuario autorizado para conectarse al servidor sshd
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: $ ssh -N -p 22 -L 10080:localhost:80 -l omar servidor.midominio.com.ar 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: $ ssh -N -p 22 -L 13306:192.168.10.21:3306 -l omar servidor.midominio.com.ar Opción
Descripción
-p 22
es el puerto al que escucha el demonio sshd de servidor.dominio.com.ar
-N
indica que no se debe iniciar una terminal tras la conexión
-L
suministra los parámetros para el túnel
13306
es el puerto en la máquina local encaminado al servidor MySQL remoto
192.168.10.21
es la dirección de la máquina a contactar desde el punto de vista del servidor sshd
3306
es el puerto que atiende el servidor MySQL a contactar
-l usuario
es el usuario autorizado para conectarse al servidor sshd
servidor.dominio.com.ar
es el servidor ssh que hace de puente entre la máquina local y el servidor MySQL
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 maquina remota. De igual forma, si habláramos de un servidor Apache, la orden sería: $ ssh -N -p 22 -L 10080:192.168.10.21:80 -l omar servidor.midominio.com.ar 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 maquina 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 redirección en 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 (un programa de KDE) 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: $ vncserver 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 maquinaremota:n Opción
Descripción
maquinaremota computadora que se encuentra ejecutando el servidor VNC :n
identificativo del servidor X lanzado por el servidor VNC
por ejemplo, krdc servidor.midominio.com.ar:1 o krdc 200.100.122.201: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: $ ssh -p puertor -N -Lplocal:maquinaremota:premoto maquinaremota Opción
Descripción
-p puertor
es el puerto al que escucha el demonio sshd de servidor.dominio.com.ar
-N
indica que no se debe iniciar una terminal tras la conexión
-L
suministra los parámetros para el túnel
plocal
es el puerto en la máquina local encaminado al servidor VNC remoto
maquinaremota es la dirección de la máquina corriendo el servidor VNC (y SSH)
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.
-l usuario
es el usuario autorizado para conectarse al servidor sshd
maquinaremota es el servidor ssh que también corre el servidor VNC
Por ejemplo, la orden $ ssh -p 22 -N -L15091:servidor.midominio.com.ar:5901 servidor.midominio.com.ar permitirá contactar con el servidor X :1 corriendo en la máquina servidor.midominio.com.ar y escuchando el puerto 5901. Sin túnel, la orden para contactar con el escritorio remoto es krdc servidor.midominio.com.ar: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: $ vncserver -kill :1
Parte 5. SSH. Opciones adicionales Todas las órdenes contenidas en este apunte se suponen impartidas por un usuario no privilegiado, de ahí el indicativo $ en las órdenes de ejemplo. Además, 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 hacemos: $ ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/home/omar/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/omar/.ssh/id_dsa Your public key has been saved in /home/omar/.ssh/id_dsa.pub The key fingerprint is: 4a:a1:ea:33:20:fe:2b:44:3f:63:19:c5:26:ca:da:11 omar@maquinalocal Como queremos no tener que suministrar contraseñas al usar el comando ssh, simplemente pulsamos Enter cuando nos solicita una frase de contraseña (passphrase). El archivo id_dsa contiene nuestra clave privada y id_dsa.pub nuestra clave pública. Ahora queda enviar la clave pública a la máquina remota para que no sea necesario el uso de contraseña. $ ssh-copy-id -i archivoclavepublica nusuarior@maquinaremota o, por ejemplo: $ ssh-copy-id -i /home/omar/.ssh/id_dsa.pub omar@servidor.midominio.com.ar
A partir de este momento, las conexiones vía ssh con la máquina remota ya no solicitarán la introducción de contraseña. Esto también permite modificar la orden para la creación de túneles para que se ejecute en segundo plano y devuelva el prompt de la línea de comandos. La orden modificada quedaría: $ ssh -N -f -p puertor -L plocal:servidorremoto:premoto -l nusuarior maquinaremota Opción
Descripción
-p puertor
es el puerto al que escucha el demonio sshd de la máquina remota maquina remota
-N
indica que no se debe iniciar una terminal tras la conexión
-f
ejecuta la orden en segundo plano (background)
-L
suministra los parámetros para el túnel
plocal
es el puerto en la máquina local encaminado al puerto del servidor remoto
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 (maquina remota)
premoto
es el puerto del servicio que se desea contactar en la máquina servidor remoto
-l nusuarior
es el usuario autorizado para conectarse al servidor sshd
maquinaremota
es el servidor ssh que hace de puente entre la máquina local y el servidor servidor remoto