SSH, ¿navaja suiza o agujero de seguridad? I/II

Seguro que a poco que hayas trasteado con la programación te sonará ssh, es “eso” que tienes para conectarte a los servidores donde están instaladas tus aplicaciones. Sin entrar en definiciones muy retorcidas, ssh es un protocolo de comunicaciones que permite establecer conexiones seguras, ya que todo el tráfico que se transmite está cifrado. ¿Esto qué quiere decir? Que si estamos transmitiendo información en una red, si alguien captura los paquetes de nuestra comunicación, no podrá saber qué es lo que estamos transmitiendo, o por lo menos no de una manera sencilla, es por esto que se puede considerar un estándar a la hora de facilitar acceso remoto a una máquina. Al estar tan extendido podemos encontrar servidores de ssh en casi todos los servidores que utilizamos, de la misma manera que existen clientes para casi cualquier plataforma: Linux, Windows, MacOS, IOS, Android...

Más allá de permitirnos conectarnos a una máquina remota para poder ejecutar comandos, nos brinda muchas más funcionalidades que pueden ayudarnos a hacer nuestro trabajo, pero a su vez puede que comprometan la seguridad de nuestros sistemas.

SFTP (SSH File Transfer Protocol)

Una funcionalidad que ofrece ssh por defecto es que nos facilita un servidor de archivos. Funcionalmente es idéntico a un servidor de FTP pero con una gran mejora, que todos las transferencias se hacen de manera cifrada sin que tengamos que configurar absolutamente nada. Al igual que al conectarnos a una terminal por ssh, si alguien intercepta paquetes de la transferencia de archivos, no podrá ver que hay dentro. 

El habilitar un servidor de archivos puede resultar una ventaja o un gran inconveniente, ya que si no queremos que nadie saque información de la máquina, teniendo un servidor de archivos, no estamos haciendo mucho por impedirlo. Y esto ¿no se puede desactivar? por supuesto que sí, evidentemente se tiene que hacer en el servidor, y en la configuración del servidor de ssh (/etc/ssh/sshd_config) bastaría con comentar una línea similar a esta dependiendo de la instalación.

Subsystem sftp /usr/lib/openssh/sftp-server

Configuración del cliente (keep-alive)

Seguro que se nos hace raro pensar que tenemos que configurar algo en un cliente de ssh, si es tan sencillo como poner un usuario y una contraseña, y la verdad es que es cierto, no es necesario nada más, pero con alguna configuración mínima, podemos obtener grandes beneficios.

Estoy convencido que a cualquiera que haya utilizado ssh, estando conectados a algún servidor, al estar un tiempo sin ejecutar nada hemos recibido un error del tipo “Se ha perdido la conexión con el servidor”, y lo que nos toca es volver a conectarnos y volver a retomar lo que estuviésemos haciendo. Dependiendo que lo que estuviésemos haciendo puede ser bastante fastidioso, por ejemplo si desde esa máquina teníamos una conexión a otra máquina, o teníamos algo a medias puede que hayamos perdido parte del trabajo.

La solución sencilla es de vez en cuando, mientras no vamos a hacer nada pulsar alguna tecla, y así la conexión se mantiene activa, pero la realidad es que al final se nos pasa y perdemos la conexión.

image 1 bl

La forma elegante es configurar un keep-alive, que como su propio nombre indica lo que hace es mantener viva la conexión. ¿Cómo se hace eso? pues depende de nuestro cliente, pero lo importante es saber que existe esa opción, y si lo queremos activar veremos cómo se hace para nuestro cliente. ¿Cómo funciona? Es muy sencillo, envía paquetes “vacíos” por la red cada determinado tiempo, para nosotros será transparente y no veremos nada. Lo único que podemos configurar es que esté activo o no, y el tiempo que pasa entre el envío de paquetes. 

Unos ejemplos de cómo configurarlo en aplicaciones muy extendidas

Putty

Tenemos que ir a Configuration > Connection

En esa pestaña en el apartado de Seconds between keepalives debemos poner el intervalo en segundos entre envíos de paquetes, 0 para desactivarlo.

image 2 bl

WinSCP

Para llegar a la configuración iremos por los menús  

Session > Sites > Sites Manager… > Edit > Advanced…> Connection 

imagge 3 bl

OpenSSH

Al ser una herramienta open source, sigue el esquema de otras muchas y lee la configuración del usuario, por eso habrá que crear un fichero en el directorio $HOME del usuario con la configuración que queremos. El fichero que hay que crear se tiene que llamar 

$HOME/.ssh/config

Y el contenido será el siguiente

Host *

    ServerAliveInterval 30

Con esta configuración de nuestros clientes, nos podemos autenticar en un servidor y la conexión nunca se cortará, y con esto tenemos un gran problema de seguridad, si nos han facilitado una contraseña temporal con una validez determinada, pasado el tiempo de validez, no se nos expulsa del servidor porque la validación de la contraseña únicamente se hacen cuando se establece la conexión. Un ejemplo práctico podría ser que nos den una contraseña con validez de un día para mirar la configuración de una aplicación, nos logamos con un keep-alive activo, y después de un mes podemos seguir conectados, pese a tener la contraseña expirada. Hay diversas formas de evitar que estas situaciones se puedan dar, pero esta tarea es responsabilidad del administrador del servidor.

xWindows (Ventanas X) X11

Esta es otra muy interesante opción que tenemos al tener un servidor de ssh. Seguramente a mucha gente le suene a chino, y no me extraña. Sin entrar en mucho detalle, es un sistema de ventanas que permite tener interfaces gráficos a las aplicaciones. Un ejemplo de uso sería arrancar una aplicación que tenga una parte gráfica, si queremos hacer esto en un servidor remoto, necesitaremos que alguien se encargue de presentar la parte gráfica, ya que la terminal únicamente es capaz de mostrar texto.

Este sistema lo que nos permite es tener la parte gráfica ejecutándose en nuestro cliente/PC, algo similar a lo que sería la parte front-end de una aplicación web, y la parte de back-end se seguiría ejecutando en el servidor.

¿Qué utilidad tiene esto? Nos permite que utilicemos aplicaciones gráficas basadas en ventanas en un entorno de línea de comandos.

¿Qué necesitamos para poder hacer esto? tener instalado un cliente de X Windows en nuestro cliente/PC, por ejemplo Xming (https://sourceforge.net/projects/xming/)

¿Cómo le indicamos a las aplicaciones donde está su servidor de X Windows? En principio no sería necesario hacerlo con el uso de SSH, que bastaría con indicar donde está su servidor de X Windows, y eso es tan sencillo como exportar una variable de entorno con la IP de nuestro PC, si la IP de nuestro PC fuese 10.0.0.138 tendríamos que ejecutar lo siguiente:

[ksh]pi@rPi3[]: export DISPLAY=10.0.0.138:0.0

Pero puede que tengamos problemas de comunicación desde el servidor hacía nuestro PC, estos problemas se solucionan si lo hacemos a través de SSH, indicando que haga una redirección de x11, que es el protocolo utilizado para las X Windows. Pero esto ya empieza a sonar más complicado, y la verdad es que lo es. Pero su utilización más simple no puede ser, en putty lo podemos activar en Connection > SSH > X11 > “Enable X11 Forwarding”

image 4 bl

Marcando este check e indicando que lo mande a nuestro PC (localhost) todas las aplicaciones que ejecutemos en el servidor remoto y requieran de xWindows se abrirán en nuestro PC, pero la carga de trabajo estará en el servidor. Para comprobar si está funcionando correctamente, podemos ejecutar alguna de las aplicaciones de prueba que suelen estar instaladas en los servidores (xclock, xeyes, xcalc...). Lo que indicamos a continuación del nombre/IP con las coordenadas donde se crearán las ventanas, con localhost:0.0 la ventana se mostrará en nuestro PC en las coordenadas 0.0, en cualquier caso, una vez se haya creado la ventana, ésta se podrá mover por la pantalla, como cualquier otra ventana.

image 5 bl

Más allá de aplicaciones que nos sirven únicamente para hacer pruebas, tenemos otras de mayor utilidad como por ejemplo el navegador web Chromium o el cliente de base de datos SQLiteBrowser.

image 6 bl

image 7 bl

Aunque se puede dar el caso en  que tengamos la posibilidad de tener estas aplicaciones en nuestro PC, la diferencia es que en los ejemplos las aplicaciones se están ejecutando en la máquina remota, y tendrán los accesos que tenga dicha máquina. Podría ser que desde nuestro PC no tengamos conectividad a una base de datos, pero desde la máquina remota si se tenga este acceso.

Conclusiones

Aunque haya podido resultar un poco espeso entender todo lo que aquí se ha contado, hemos podido ver que con una pequeña inversión de tiempo podemos tener un gran beneficio para nuestro día a día. A pesar de no utilizar todo lo expuesto, por lo menos somos un poco más conscientes de las grandes capacidades y virtudes que se esconden detrás de ese inofensivo comando de solo tres letras que es ssh.