¿Qué es el protocolo SSH y para qué se utiliza?

Para qué crear un túnel Secure Shell

Recientemente se publicaba en los medios que un troyano, haciendo uso del protocolo SSH, había logrado infectar a miles de ordenadores Linux que empleaba para minar Bitcoin.

Pero con casi toda seguridad, si has llegado a este post, no es para hacer de imitador y aprovechando que la cotización de la criptomoneda está a máximos históricos, hacerte millonario. Si has llegado hasta aquí es porque:

1. Necesitas hacer algo con un servidor y te han dicho que debes hacerlo por SSH.
2. Crees que tu conexión no es todo lo segura que debería para hacer lo que sea que estés haciendo (a veces es mejor ni preguntar…).

¡Pues estás de suerte! En este artículo, que es el primero de toda una serie de artículos sobre SSH, te vamos a explicar qué es, para qué se usa y cuál fue su origen. Y con los siguientes artículos te explicaremos “Cómo Conectarte por SSH en Windows, Linux y MacOs”, “Cuáles son los comandos más comunes de SSH para gestionar un servidor”, “Cómo configurar un túnel SSH para que sea aún más seguro”, y por supuesto, “cómo navegar por internet ocultando tu rastro a través de túneles SSH”.

Pasa, disfruta, aprende, y sobretodo, ¡COMPARTE!

El origen de SSH y sus antecesores

Ante la necesidad de controlar a distancia otros ordenadores, surgió Rlogin. Un programa que a través de r-commands (comandos UNIX) permitía a un usuario loguearse en otro sistema (el host), enviar órdenes y que éstas fuesen ejecutadas en destino.

Todo el proceso se realizaba a través del protocolo TCP/IP, permitiendo así el control de un ordenador en remoto, siempre y cuando éste estuviese conectado a alguna red.

El problema de Rlogin, era que almacenaba los credenciales de conexión en archivos en local, de manera que cuando un cliente deseaba conectar con el host, la conexión se establecía de manera automática. Esto suponía un importante agujero de seguridad ya que, establecida la conexión, si se desatendía el terminal de comandos, otra persona podía tomar el control de tu ordenador y del host. Por otro lado, cualquiera podía piratear los rhost files consiguiendo así las credenciales y clonándolas en otro cliente para poder acceder al host desde cualquier otro dispositivo.

Ante esta situación, surgió Telnet, que manteniendo la esencia de su predecesor añadía ciertas mejoras, principalmente en lo que a la seguridad se refiere. Telnet enviaba las credenciales por la red, de manera que el host detectaba si eran correctas y aprobaba el acceso.

Con el tiempo, Telnet llegó a ser el protocolo más usado para comunicaciones en remoto, pero pronto se hizo patente otro agujero de seguridad: Enviaba las credenciales sin cifrar, como texto plano. De esta forma podían sniffearse y ser robadas.

SSH, creado en su primera versión por el finlandés Tatu Ylönen en 1995, nació bajo licencia libre, pero tras su gran aceptación registró la marca y fundó la empresa SSH Communications Security para comercializarla. Dejándola libre exclusivamente para uso doméstico y académico.

Su principal diferencia con respecto a Telnet radica en que se encripta la sesión, teniendo controles de autenticación en ambos extremos, y cifrando la información que se envía, añadiendo así un paso de gigante en cuanto a la seguridad de las comunicaciones cliente-servidor.

Pero nada es inhackeable y acabó por descubrirse una vulnerabilidad que permitía introducir datos en los flujos cifrados.

En 1997 se comenzó a desarrollar la versión 2, que solventaba este error e incorporaba el protocolo SFTP, que añadía la misma filosofía de encriptación de sesiones al clásico protocolo de trasferencia de archivos, FTP.

A principios de 1999 y motivados por el cambio de licencia de SSH, los creadores del Sistema Operativo OpenBSD, comenzaron a escribir otra versión del protocolo, que es la que empleamos hoy día. Esta segunda versión (OpenSSH) es de código libre, y actualmente es mantenida por Red Hat Entrerprise Linux.

Descripción técnica: Proceso de conexión cliente-servidor

‘Handshake’: Acuerdo de las claves que permitirán la creación de una capa de transporte Cliente – Servidor.

Esta capa de transporte encriptará y desencriptará toda comunicación durante la sesión, verificando la integridad de la información emitida y comprimiéndola para acelerar las peticiones.

Se establece de la siguiente forma:

1º – Cliente –> Servidor: Inicio conexión TCP sobre puerto 22

2º – Cliente — Servidor: Detección de la versión SSH y establecimiento del algoritmo de cifrado.

3º – Servidor –> Cliente: Envío de la clave pública al cliente (se queda con su clave privada).

4º – Cliente: El cliente compara la clave pública del servidor con la suya propia, y si hay coincidencia, genera una clave de sesión aleatoria.

5º – Cliente –> Servidor: Se crea un mensaje con la clave de sesión aleatoria y el algoritmo seleccionado para encriptar los mensajes, y encripta todo ello con la clave pública del servidor. Se lo hace llegar al servidor

6º – Cliente: Desencripta el contenido con su clave pública y comprueba la coincidencia en los datos recibidos. Si es correcto se inicia la sesión.

Este proceso permite comprobar en todo momento (aun después de la conexión inicial), que el cliente está conectado siempre al mismo servidor. Evitando así que un ataque reemplace el Servidor quedándose con las claves (envenenamiento del DNS o spoofing de IP).

El proceso se realiza con una encriptación de 128 bits. Y a partir de ahí, todas las comunicaciones mantendrán dicha encriptación.

Autenticación: Tras crear un túnel de transmisión de información seguro…

1º – Servidor –> Cliente: Le hace llegar los sistemas de autenticación soportados (firma privada o contraseña).

2º – Cliente –> Servidor: El usuario emplea su sistema de autenticación, por ejemplo una contraseña, se cifra, y es enviada al servidor.

3º Servidor: Verifica que la contraseña es correcta y abre múltiples canales a través de una técnica llamada multiplexar. Cada uno de esos canales gestionará una sesión de terminal.

Durante la sesión, tanto servidor como cliente pueden crear o cerrar canales nuevos, identificándose éstos numéricamente y siendo enviados en la siguiente transmisión. De esa manera, cuando el cliente cierre una sesión, el servidor podrá cerrar todos los canales abiertos con ese cliente durante esa sesión.

¿Te ha parecido interesante? ¡Compártelo!