Handshake de SSH y autenticación mediante claves de host

SSH comienza con una conexión TCP al puerto 22. Una vez establecida, el cliente y el servidor intercambian cadenas de versión, como SSH-2.0-OpenSSH_9.3, que identifican la versión del protocolo y la implementación. Este intercambio de versiones permite que ambas partes confirmen la compatibilidad antes de continuar.

Después del intercambio de versiones, ambas partes envían paquetes SSH_MSG_KEXINIT con una lista de los algoritmos compatibles. Estas listas incluyen métodos de intercambio de claves, tipos de claves de host, cifrados simétricos, algoritmos MAC y compresión. La intersección de ambas listas determina los algoritmos elegidos para la sesión.

La clave de sesión se establece mediante un algoritmo de intercambio de claves, como Diffie-Hellman o ECDH. El cliente y el servidor generan cada uno un par de claves efímeras, intercambian valores públicos y calculan de forma independiente el mismo secreto compartido. Este secreto compartido sirve como semilla para derivar la clave de sesión sin transmitirse directamente en ningún momento.

El servidor demuestra su identidad firmando el hash del intercambio de claves con su clave privada de host. La clave de host puede ser RSA, ECDSA o el formato moderno Ed25519. El cliente utiliza la clave pública correspondiente para verificar esta firma y confirmar que se está comunicando con el servidor legítimo y no con un impostor.

En la primera conexión con un servidor nuevo, el cliente aún no conoce la clave pública de host. SSH muestra la huella digital de la clave y solicita al usuario que la acepte. Este modelo de confianza en el primer uso almacena la clave en known_hosts y detecta cambios en conexiones posteriores, con una advertencia sobre posibles ataques de intermediario.

La forma más segura de verificar la clave de host de un servidor nuevo es mediante un canal externo. Un administrador puede leer la huella digital del servidor en persona o a través de un canal seguro verificado y compararla con la que muestra el cliente SSH. Esto evita aceptar silenciosamente una clave fraudulenta durante la primera conexión.

El archivo known_hosts almacena líneas con el formato: hostname algorithm base64-key comment. Cada entrada representa una identidad de servidor de confianza. Al conectarse a un host que ya está incluido en known_hosts, SSH verifica que la clave presentada coincida con la almacenada y rechaza la conexión si no coinciden.

Después del intercambio de claves, ambas partes derivan de forma independiente las claves de sesión utilizando el secreto compartido, el hash del intercambio y el identificador de sesión. Se derivan claves independientes para cada dirección de comunicación y para las operaciones de cifrado y MAC. Esto significa que las claves utilizadas para el tráfico del cliente al servidor son diferentes de las utilizadas para el tráfico del servidor al cliente.

Una vez establecidas las claves de sesión, todas las comunicaciones posteriores de SSH se cifran y autentican. El cifrado negociado, como AES-256-GCM o ChaCha20-Poly1305, protege la confidencialidad, mientras que el MAC garantiza la integridad. Incluso el nombre de usuario y las credenciales de autenticación se envían dentro de este túnel cifrado.

Las claves de host RSA de 2048 o 4096 bits tienen una compatibilidad amplia, pero son más lentas. Las claves ECDSA basadas en curvas NIST son más rápidas, aunque algunas personas desconfían de los parámetros de las curvas NIST. Las claves Ed25519 basadas en Curve25519 son la recomendación moderna: son pequeñas, rápidas, ofrecen una seguridad sólida y no dependen de los parámetros de las curvas NIST. La mayoría de los servidores SSH modernos ofrecen Ed25519 de forma predeterminada.

El protocolo de enlace de SSH consta de los siguientes pasos: conexión TCP, intercambio de versiones, negociación de algoritmos, intercambio de claves para establecer las claves de sesión, verificación de la clave de host del servidor y autenticación del usuario. Todos los pasos posteriores al intercambio de versiones tienen lugar dentro de un canal cifrado y protegido contra modificaciones, establecido durante la fase de intercambio de claves.

¿Cómo verifica un cliente la clave de host del servidor SSH en las conexiones posteriores a la primera?

En esta lección: TCP se conecta al puerto 22, se intercambian las cadenas de versión, la negociación de algoritmos selecciona los cifrados y métodos de intercambio de claves, ECDH o DH establece un secreto compartido, las claves de sesión se derivan por separado para cada dirección, el servidor se autentica mediante la firma de su clave de host y el cliente verifica la clave en known_hosts utilizando TOFU durante la primera conexión.