Secure Shell

Índice

1. Introducción
2. Descripción del tema en concreto

2.1 SSH1
2.2 SSH2
2.3 Distribuciones

3. Ejemplo práctico de su utilidad
4. Conclusiones
5. Fuentes

1. Introducción

SSH es un protocolo muy usado, sobretodo en sistemas UNIX-like. Se trata de un protocolo abierto, fiable y seguro que inicialmente servía para conectar a máquinas remotas, pero que con el tiempo se ha usado para encapsular otros datos, de manera que podemos hacer pasar cualquier cosa por él. Pretende ser un reemplazo seguro para aplicaciones tradicionales no seguras, como telnet, rlogin, rsh y rcp. Su versión 2 (SSH2) proporciona también sftp, un reemplazo seguro para FTP.

Es un protocolo con un alto nivel de cifrado, cosa que lo hace propicio para comunicaciones de datos sensibles.

SSH (Secure SHell) es también el nombre del programa que implementa dicho protocolo.

2. Descripción del tema en concreto

SSH trabaja de forma similar a como lo hace TelNet (explicado también en esta wiki) permitiendo las mismas aplicaciones que él y ampliando funcionalidades en la versión 2. La diferencia principal es que SSH usa técnicas de cifrado que hacen que la información que viaja por el medio de comunicación vaya de manera no legible y ninguna tercera persona pueda descubrir el usuario y contraseña de la conexión ni lo que se escribe durante toda la sesión.

Básicamente, sus aplicaciones son:

Manejar por completo un ordenador remoto mediante un intérprete de comandos.
Redirigir el tráfico de X para poder ejecutar programas gráficos si tenemos un Servidor X arrancado en el ordenador local. Ésto se hace redirigiendo la variable DISPLAY del ordenador remoto para que apunte a la pantalla X del ordenador local y aceptando el host remoto en el servidor X local con el comando xhost +IP-remota.
Copiar datos de forma segura (tanto ficheros sueltos como simular sesiones FTP cifradas, SFTP).
Gestionar claves RSA para no escribir claves al conectar a las máquinas.
Pasar los datos de cualquier otra aplicación por un canal seguro de SSH mediante un túnel SSH.

La primera versión del protocolo y el programa eran libres y los creó un sueco llamado Tatu Ylönen, pero su licencia fue cambiando y terminó apareciendo la compañía 'SSH Communications Security', que lo ofrecía gratuitamente para uso doméstico y académico, pero exigía el pago a otras empresas.

En el año 1997 (dos años después de que se creara la primera versión) se propuso como borrador en la IETF.

A principios de 1999 se empezó a escribir una versión que se convertiría en la implementación libre por excelencia, la de OpenBSD, llamada OpenSSH.

A partir de entonces han salido muchas versiones de programas que lo implementan. Cabe destacar la ausencia de SSH en el ?HyperTerminal de Windows en todas sus versiones.

SSH es un protocolo para iniciar sesiones en máquinas remotas que ofrece autenticación, confidencialidad e integridad. Consta de tres componentes:

Protocolo de transporte: normalmente opera sobre TCP/IP dando autenticidad, confidencialidad e integridad.
Protocolo de autenticación de usuario: autentica al usuario ante el servidor.
Protocolo de conexión: multiplexa un canal encriptado en diversos canales lógicos. Éste requiere que los servidores tengan "llaves", las cuales son usadas por los clientes cada vez que se conectan a un servidor para verificar que no fue suplantado. Una llave es un número codificado y encriptado en un archivo. Para la encriptación de llaves, OpenSSH ofrece los algoritmos RSA y DSA (de los cuales para la versión 2 se recomienda DSA).

El protocolo SSH cuenta con dos versiones. La primera de ellas se mantiene por motivos de compatibilidad, pero se recomienda generalmente el uso de la segunda, por su mayor seguridad. Entre los fallos de la primera versión caben destacar:

Fallos estructurales que le hacen vulnerable a ciertos tipos ataques (ataques de replay)
Ataque del tipo "Man In The Middle" (intercepción las claves públicas en el intercambio de las mismas)

En cambio, aún conserva ciertas ventajas sobre SSH2:

Está soportado en más plataformas que SSH2
Permite autentificación de tipo .rhosts (propuesta en SSH2), mientras que permite métodos de autentificación más diversos (AFS, Kerberos, etc.)
Tiene mejor rendimiento que SSH2

SSH, dependiendo de su versión utiliza diferentes algoritmos de cifrado:

SSH1: DES, 3DES, IDEA, Blowfish
SSH2: 3DES, Blowfish, Twofish, Arcfour, Cast128-cbc

El cifrado utilizado para cuestiones de autentificación utiliza RSA para SSH1 y DSA para SSH2.

SSH permite autentificarse utilizando uno o varios de los siguiente métodos:

Password
Sistema de clave pública
Kerberos (SSH1)
Basado en el cliente (por relaciones de confianza en SSH1 y sistema de clave pública en SSH2)

Existen además parches que permiten realizar autentificación de otras maneras.

SSH protege contra los siguientes tipos de ataques:

IP Spoofing: un ordenador trata de hacerse pasar por otro ordenador (en el que confiamos) y nos envía paquetes "procedentes" del mismo. SSH es incluso capaz de proteger el sistema contra un ordenador de la propia red que se hace pasar por el router de conexión con el exterior.
Enrutamiento de la IP de origen: un ordenador puede cambiar la IP de un paquete procedente de otro, para que parezca que viene desde un ordenador en el que se confía.
DNS spoofing: un atacante compromete los registros del servicio de nombres.
Intercepción de passwords y datos a través de la red.
Manipulación de los datos en ordenadores intermediarios.
Ataques basados en escuchar autentificación contra servidores X-Windows remotos.

SSH considera la red como un medio hostil en el que no se puede confiar. Un atacante, podrá forzar a que SSH se desconecte, pero no podrá descifrar o reproducir el tráfico, o introducirse en la conexión.

Todo esto, de todos modos, es sólo posible si se utiliza algún tipo de cifrado. SSH permite no usar cifrado (cifrado de tipo "none"), pero esta opción no debería utilizarse. Hay que tener en cuenta que SSH no sirve de nada si el atacante consigue hacerse con el control de la máquina como root, ya que podrá hacer que SSH quede inutilizado.

2.1 SSH1

Características del protocolo

El sevidor y el cliente se conectan a través de una red IP no segura.
La conexión siempre se inicia por parte del cliente. El servidor está escuchando un puerto determinado, esperando la conexión, y puede atender a varios clientes.
Cuando el cliente se conecta al servidor, el servidor acepta la conexión y responde enviando su identificación de versión, a lo que el cliente responde enviando la suya. Esta información valida que la conexión se realizó en el puerto correcto, establece la versión del protocolo utilizada, y la versión del software utilizada por cada uno de ellos. Esta información no se envía cifrada, y es perfectamente legible. Si cualquier lado de la conexión no acepta o no entiende esta información, se cierra la conexión.
Una vez a terminado la fase de identificación, ambos lados comienzan una transmisión según un protocolo binario. El servidor envía su clave de equipo (la clave RSA del propio equipo), la clave del servidor (una clave RSA generada cada hora), y otras informaciones al cliente. El cliente genera una clave de sesión de 256 bits, la cifra utilizando ambas claves RSA y envía la clave cifrada, junto con el tipo de cifrado seleccionado al servidor.
Ambos lados comienzan ahora a enviar datos cifrados mediante la clave generada y el algoritmo seleccionado. El servidor envía un mensaje de confirmación cifrado al cliente.
Tras eso, el cliente se autentifica utilizando uno de los métodos de autentificación soportados:
- basada en los ficheros ".rhosts" o "/etc/hosts.equiv", por defecto no permitida
- esta misma junto con autentificación del ordenador cliente basada en RSA
- autentificación RSA
- y autentificación por password
Tras una correcta autentificación, el cliente envía una serie de peticiones para comenzar la sesión, como establecer una sesión de consola remota, forwarding de X11 o de un puerto TCP/IP, ejecutar un comando, etc.

Al ejecutar una consola o un comando, la sesión entra en modo interactivo. En este modo, se envían datos en ambos sentidos, pueden abrirse nuevas conexiones, etc. Esta sesión generalmente termina cuando el servidor envía el código de terminación del programa ejecutado al cliente.

El protocolo reserva cierta información para permitir extenderlo en el futuro:

Envío de la versión del protocolo
El primer paquete enviado por ambas partes, contiene una serie de flags, que pueden utilizarse para acordar el uso de extensiones compatibles
En las fases de autentificación y preparación de la sesión, el cliente realiza peticiones al servidor, de modo que si se envía una petición no permitida por el servidor, éste simplemente devuelve que la petición ha fallado. Esto permite añadir nuevos métodos de autentificación y operaciones de preparación. En cambio, la sesión interactiva, no permite la negociación de extensiones. Éstas deberían negociarse en las fases anteriores.

Formato de los paquetes

Tras el envío de los strings de identificación, ambas partes envían paquetes con el siguiente formato:

1

2

3

4

Tamaño del paquete

1 a 8 bytes de relleno aleatorio

(cont.relleno aleat.)

Tipo paquete

DATOS

CRC

*Nota: Longitud de relleno + tipo + datos + CRC siempre múltiplo de 8 bytes.

Tamaño del paquete: 32 bits. Es el tamaño del paquete, sin incluir el campo tamaño, y el relleno. El máximo es de 262144 bytes.
Relleno: 1 - 8 bytes de datos aleatorios (o ceros si no se utiliza cifrado). El tamaño del relleno es de (8 - (tamaño % 8)) bytes. El hecho de que este relleno sea aleatorio dificulta los ataques.
Tipo de paquete: 8 bits. El valor 255 está reservado para futuras ampliaciones.
Datos: con un tamaño igual al valor del campo "tamaño" menos 5.
Bytes de chequeo: 4 bytes. CRC con el polinomio 0xedb88320 del relleno, tipo de paquete y datos. Se calcula antes del cifrado.

Los paquetes de datos tienen, además, las siguientes características:

El paquete puede cifrarse utilizando cualquiera de los algoritmos soportados.
La longitud de la parte cifrada (relleno + tipo + datos + chequeo) es siempre múltiplo de 8 bytes.
Típicamente, el cifrado se utiliza sobre todos los paquetes, como si fuesen una única secuencia.
El cifrado se activa cuando el cliente envía la clave de sesión. El algoritmo de cifrado es seleccionado por el cliente.

Compresión de los paquetes:
Si la compresión está soportada, el tipo de paquete y los datos se comprimen utilizando el algoritmo gzip. En este caso, el tamaño del paquete indica el tamaño de los datos comprimidos, más 4 para el CRC. El relleno se calcula según los datos comprimidos, para que los datos cifrados sean múltiplo de 8 bytes.

Cifrado de paquetes:
El protocolo soporta distintos métodos de cifrado. Durante la inicialización de la sesión, el servidor envía al cliente los métodos que soporta, y el cliente elige uno de estos métodos, y genera una clave aleatoria de 256 bits que también envía al servidor. Todas las implementaciones deben de soportar el algoritmo 3DES, siendo los demás opcionales. Para cifrar los datos, las partes cifradas de cada paquete se consideran un flujo de datos continuo, cuyo tamaño es siempre múltiplo de 8 bytes. Las partes cifradas de paquetes consecutivos se cifran como si se tratase de un buffer continuo de datos. Los datos se cifran independientemente en cada dirección.

Otras opciones de los aquetes de datos:

El puerto por defecto para el servidor es el 22.
El cliente puede conectarse desde cualquier puerto, pero si quiere utilizar autentificación mediante ".rhosts" o "/etc/hosts.equiv", debe conectarse a través de un puerto privilegiado (menor a 1024).
El campo IP "Tipo de Servicio" debería de ser IPTOS_LOWDELAY para conexiones interactivas, y IPTOS_THROUGHPUT para las no interactivas.
Se recomienda así mismo que se utilicen señales para comunicar que la conexión sigue activa, para detectar si alguno de los lados ha cortado la conexión de modo inusual.

Identificación de la versión del protocolo:

Una vez que se ha abierto el socket, el servidor envía un string con el formato "SSH-<num_mayor_del_protocolo>.<num_menor_del_protocolo>-<versión>\n". Los dos primeros campos identifican la versión del protocolo, y el último campo, la versión del software del servidor.
El cliente envía después su propia información. Si el servidor tiene un protocolo menor que el cliente, y éste puede emularlo, envía la versión menor.
En caso contrario, envía su propia versión. El servidor compara la versión enviada por el cliente con la suya, y determina si pueden trabajar o no. El servidor decidirá desconectarse, o enviará el primer paquete binario, y ambas partes utilizarán después la versión del protocolo acordada.

Intercambio de claves y autentificación del equipo servidor:

El primer mensaje enviado por el servidor envía la clave del equipo, la clave pública del servidor, los algoritmos de cifrado soportados, los métodos de autentificación soportados y las extensiones. También contiene un número aleatorio de 64 bits (cookie). Este paquete se envía sin cifrar.

Ambas partes calculan un identificador de sesión del siguiente modo:

session_id = MD5(hostkey || serverkey || cookie)

El cliente responde con un mensaje que contiene el tipo de cifrado elegido, una copia del cookie, y la clave de sesión de 256 bits cifrada con ambas claves del servidor. Este mensaje no se cifra.
Una vez que se ha enviado la clave de sesión, el cliente cifrará todos los paquetes salientes y descifrará todos los paquetes entrantes.
Una vez que el servidor recibe la clave, y activa el cifrado, envía al cliente un mensaje indicando el éxito de la operación.
La clave de equipo del servidor se recomienda que tenga 1024 bits, y la clave del cliente, 768 bits. La clave mínima no puede ser menor de 512 bits.

El nombre de usuario:

El cliente envía al servidor un mensaje indicando el nombre de usuario con el que se quiere conectar.
El servidor valida que el usuario existe, si se necesita autentificación y responde con un mensaje de éxito (no se necesita autentificar el usuario) o fallo (se necesita autentificación, o el usuario no existe).
Si el usuario no existe, se devolverá fallo a todos los mensajes, excepto al mensaje de desconexión, al mensaje "ignore" y al mensaje "debug", pero seguirá escuchando al cliente, de modo que este no puede saber si el usuario existía o no.

Fase de autentificación:
Si no se acepta el login automáticamente, el cliente pide al servidor distintos métodos de autentificación de manera aleatoria tantas veces como desee. Si la autentificación es correcta se devolverá un mensaje de éxito, y si falla, un mensaje de fallo.

Autentificación por RHOSTS:
- El cliente envía un mensaje con el nombre del usuario cliente. El servidor verifica este nombre contra los ficheros "/etc/hosts.equiv" y ".rhosts" (sistemas UNIX). La conexión debe de venir desde un puerto privilegiado.
- Este tipo de verificación no suele activarse puesto que puede sufrir diversos ataques.
Autentificación por RHOSTS y RSA:
- El cliente no sólo envía el nombre de usuario, sino también su clave pública RSA. El servidor autentifica al cliente por el método RHOSTS, y si se verifica, comprueba si conoce su clave pública, y si la enviada es la misma almacenada en el servidor.
- Si cualquiera de estos pasos no se cumple, se devolverá un mensaje de fallo.
- En caso contrario, se someterá al cliente a un desafío RSA con la clave pública del cliente. El cliente deberá descifrar un mensaje cifrado con su clave pública, utilizando su clave privada, y enviará la respuesta al servidor, que verificará si se ha conseguido pasar el desafío o no.
Autentificación por RSA:
- En este caso, el cliente envía su clave pública, y si el servidor la admite, envía al cliente un desafío RSA.
- En el caso de que el cliente lo supere, se permitirá el acceso del mismo.
Autentificación por password:
- El cliente envía al servidor el password del usuario, en texto plano (aunque lo normal será que viaje cifrado).
- Si el password es correcto, se permitirá el acceso.

Una vez que el servidor ha admitido la conexión por parte del cliente, se negocian las opciones que van a utilizarse durante el intercambio de datos.

Sesión interactiva e intercambio de datos:

Durante una sesión interactiva, los datos de salida el proceso en ejecución en el servidor se redireccionan a "stdout" o "stderr" en el cliente, y cualquier entrada disponible en "stdin" en el cliente se envía al programa en el servidor. El envío de datos es asíncrono, y tanto el cliente como el servidor pueden enviar datos al mismo tiempo.
Cuando la aplicación termine de ejecutarse en el servidor, se enviará un mensaje con el estado de finalización del programa, y se cerrará la conexión.
Además, de esto, la conexión puede ser cerrada en cualquier momento por cualquiera de los dos ordenadores.

2.2 SSH2

Características del protocolo

Cada servidor debería de tener una clave de equipo. Es posible tener varias, con distintos algoritmos, e incluso varios equipos pueden compartir la misma clave. Si un equipo tiene claves, al menos debe de tener una clave utilizando el algoritmo obligatorio (DSS).

La clave se utiliza para verificar que el cliente está conectado al servidor correcto, para lo que el cliente debe conocer de antemano la clave pública del servidor. Pueden utilizarse dos modelos:

El cliente tiene una base de datos que asocia servidores con sus correspondientes claves públicas.
Las asociaciones vienen dadas por una autoridad de certificación.

El protocolo permite que, la primera vez que el cliente se conecte con un servidor, no se compruebe su clave pública, con lo que esta primera vez no sería necesaria, pero esto hace que la conexión sea vulnerable, por lo que no se recomienda, aunque a veces es necesaria esta opción. Todas las implementaciones del protocolo deberían hacer todo lo posible por comprobar siempre esta clave.

Además, está diseñado de manera que pueda resultar fácilmente extensible, añadiendo nuevos algoritmos, protocolos, tipos de datos, etc.

Asimismo permite negociar el cifrado, la integridad, el intercambio de claves, la compresión, y los algoritmos y formatos de las claves públicas. Los algoritmos de cifrado, integridad, clave pública y compresión pueden ser diferentes en cada sentido de la conexión.

Consideraciones de seguridad:

Los algoritmos de integridad, cifrado y clave pública utilizados son conocidos y ampliamente probados.
Los algoritmos utilizan claves lo suficientemente largas como para resistir durante décadas los más fuertes ataques de criptoanálisis.
Como los algoritmos se negocian, si uno se ve comprometido es posible negociar el uso de otro sin cambiar el protocolo.

Protocolo de transporte:
Este protocolo proporciona cifrado fuerte, autentificación del servidor y protección de la integridad de los datos. No autentifica al cliente, sino que permite hacer esto en un protocolo superior.

El protocolo de transporte negocia el método de intercambio de claves, el algoritmo de clave pública, el algoritmo de cifrado simétrico, el algoritmo de autentificación de mensajes y el algoritmo de hash. En el mejor de los casos, se necesitaran dos intercambios de mensajes entre el cliente y el servidor para esta negociación, y en el peor, tres.

Establecimiento de la conexión:

El servidor generalmente escucha conexiones en el puerto 22 de TCP/IP.
Cuando se establece la conexión, ambos lados deben enviar un string de identificación con el formato: "SSH-versión_protocolo-versión_software comentarios\r\n"

Formato de los paquetes:
Cada paquete tiene el siguiente formato:

1

2

3

4

Tamaño del paquete

Tamaño relleno

DATOS

(cont. DATOS)

Relleno aleatorio

MAC

*Nota: El tamaño mínimo del paquete es 16 bytes, y el tamaño máximo del paquete debe de poder enviar 32768 bytes de datos sin comprimir, con un tamaño total del paquete de 35000 bytes. Las implementaciones deberían de soportar paquetes mayores para tareas específicas.

Tamaño del paquete, 4 bytes: el tamaño del paquete sin incluir el campo MAC ni el propio campo tamaño.
Tamaño del relleno, 1 byte: el tamaño del relleno.
Datos, (tamaño paquete - tamaño relleno – 1) bytes: los datos útiles del paquetes. Si la compresión está activada, está comprimido. Inicialmente, la compresión debe de estar desactivada ("NONE").
Relleno aleatorio, tamaño del relleno bytes: relleno para que el tamaño de todo el paquete, excepto el campo mac, tenga un tamaño múltiplo de 8, o el tamaño del bloque de cifrado, lo que sea mayor. Tiene que tener, como mínimo, 4 bytes, y cómo máximo 255.
MAC (message authentication code), n bytes: bytes para la autentificación del mensaje.

Compresión y cifrado:
Si se ha negociado la compresión, el campo de datos estará comprimido según el algoritmo negociado. El campo del tamaño y la MAC se calcularán según los datos comprimidos. El cifrado se realizará tras la compresión.

La compresión debe de poder negociarse independientemente para cada sentido de la transmisión.

Es obligatorio no soportar compresión, y opcional soportar compresión con el algoritmo "zlib".

El algoritmo de cifrado se negociará durante el intercambio de claves. Los campos cifrados serán: tamaño del paquete, tamaño del relleno, datos y relleno, después de ser comprimidos si la compresión está activa.

Los datos enviados en una dirección deberían de ser tratados como un flujo continuo de datos, y las claves de los algoritmos deberían tener, al menos 128 bits.

Los algoritmos pueden ser diferentes en cada dirección de la comunicación.

El único algoritmo requerido es el 3des-cbc, aunque pueden implementarse una gran cantidad de algoritmos opcionales.

Es también posible especificar que el tráfico no sea cifrado, con lo que se perdería la confidencialidad, por lo que no se recomienda.

Integridad de los datos:
En cada paquete se introduce un código de autentificación de mensaje (MAC) calculado a partir de una clave compartida por el cliente y el servidor, el número de secuencia del paquete, y el contenido del mismo.

El algoritmo es independiente en cada sentido de la conexión.

El único algoritmo que ha de implementarse de manera obligatoria es el algoritmo hmac-sha1.

Métodos de intercambio de claves:

El algoritmo requerido por toda implementación es el algoritmo DSS, aunque pueden implementarse muchos más.

El tipo de clave debe conocerse de antemano (por ejemplo, especificándolo en la negociación del algoritmo). Por ello es denominada clave pública.

Intercambio de claves

Cada equipo envía una lista de los algoritmos que soporta. Cada una de las partes tiene un algoritmo preferido para cada una de las categorías, y se presupone que la mayoría de las implementaciones van a usar siempre el mismo algoritmo preferido. Cada parte puede suponer qué algoritmo está utilizando el otro equipo, y puede enviar un paquete de intercambio de claves según ese algoritmo si corresponde con el algoritmo predefinido.

Esta suposición es incorrecta si:

El algoritmo de intercambio y/o el algoritmo de clave de equipo se presuponen de manera incorrecta (el algoritmo predefinido es distinto en el cliente y en el servidor)
No pueden ponerse de acuerdo en cualquiera de los otros algoritmos

En caso contrario, la suposición se considera correcta, y el primer paquete enviado debe de ser gestionado como el primer paquete de intercambio de claves.

De todos modos, si la suposición es incorrecta, y se ha enviado algún paquete de intercambio de claves, estos paquetes serán ignorados, y el lado implicado deberá de enviar un paquete de inicio correcto.

La autentificación del servidor en el intercambio de claves puede ir implícita.

Tras un intercambio de claves con autentificación implícita, el cliente debe esperar una respuesta a su petición de servicio antes de enviar más datos.

Negociación de algoritmos

El intercambio de claves comienza con un paquete enviado por ambas partes con la siguiente información:

Código de comando: 1 byte.
cookie: 16 bytes.
Algoritmos de intercambio de claves: string.
Algoritmos de clave de servidor: string.
Algoritmos de cifrado cliente/servidor: string.
Algoritmos de cifrado servidor/cliente: string.
Algoritmos de compresión cliente/servidor: string.
Algoritmos de compresión servidor/cliente: string.
Algoritmos de mac cliente/servidor: string.
Algoritmos de mac servidor/cliente: string.
Lenguajes cliente/servidor: string.
Lenguajes servidor/cliente: string.
Aiguiente paquete es el primero de intercambio de claves: boolean.
Reservado para extensiones: Entero (32 bits).

El primer algoritmo de cada lista debe de ser el preferido por la parte (el que se presupondrá), y ninguna lista de algoritmos puede ser vacía.

Si ambas partes tienen el mismo algoritmo de intercambio de clave, se utilizará ese algoritmo. En caso contrario, se seguirá el siguiente algoritmo, iterando sobre los algoritmos soportados por el cliente. Se elegirá el primero que cimpla las siguientes condiciones:

Esté soportado por el servidor.
Si necesita cifrado, hay un algoritmo de cifrado de clave de host (clave del equipo servidor) en el servidor que también está soportada en el cliente.
Si necesita una clave del equipo servidor con firma, este algoritmo de firma existe en el servidor, y en el cliente.
Si ningún algoritmo satisface estas condiciones, ambos lados deben desconectarse.

Tras el envío de este paquete, se produce el intercambio de claves según el algoritmo escogido.