SSH: protección del acceso remoto

SSH-1, el protocolo Secure Shell original, contenía un fallo de diseño fundamental que permitía a un atacante activo insertar datos arbitrarios en una sesión cifrada sin ser detectado. SSH-2, un rediseño completo del protocolo publicado en 2006 como RFC 4251-4254, solucionó estas debilidades mediante protocolos separados para las capas de transporte, autenticación y conexión, además de una comprobación de integridad más sólida mediante HMAC. SSH-1 está obsoleto y ningún servidor moderno debería habilitarlo.

El protocolo de la capa de transporte de SSH gestiona el intercambio inicial de claves y establece un canal cifrado y protegido contra modificaciones. Negocia los algoritmos para el intercambio de claves (normalmente ECDH), la autenticación del host (normalmente Ed25519 o RSA), el cifrado simétrico (normalmente AES-256-CTR o ChaCha20-Poly1305) y el MAC (normalmente HMAC-SHA2-256). Cada paquete posterior se cifra y se comprueba su integridad mediante los algoritmos negociados.

Una vez protegida la capa de transporte, la capa de autenticación de usuarios negocia cómo demuestra el usuario su identidad al servidor. Tres métodos habituales son la contraseña (el usuario escribe una contraseña, que se envía cifrada a través de la capa de transporte), la clave pública (el usuario demuestra que posee una clave privada correspondiente a una clave pública autorizada en el servidor) y GSSAPI (integración del inicio de sesión único de Kerberos para entornos empresariales).

La capa de conexión de SSH multiplexa varios canales lógicos sobre una única conexión de transporte cifrada. Una sesión SSH habitual tiene un canal para el shell interactivo. Los canales adicionales permiten la redirección de puertos, la redirección de X11 y la transferencia de archivos mediante SFTP, todo ello compartiendo la misma conexión autenticada y cifrada. Las solicitudes de canal permiten al cliente solicitar un pseudoterminal, establecer variables de entorno o ejecutar un comando específico.

Al conectarse por primera vez a un servidor SSH, el cliente recibe la clave del host del servidor y debe decidir si confía en ella. La política predeterminada es Trust On First Use (TOFU): se solicita al usuario que verifique la huella digital de la clave (normalmente mostrada como un hash como SHA256:...) y, si la acepta, se almacena en el archivo known_hosts. En las conexiones posteriores, la clave almacenada se compara con la que presenta el servidor, y cualquier discrepancia activa una advertencia contundente sobre posibles ataques de intermediario.

El archivo known_hosts, almacenado en ~/.ssh/known_hosts, mantiene una base de datos de las claves de host de los servidores, indexadas por nombre de host y dirección IP. Cada entrada vincula la dirección de un servidor con su clave pública. Si la clave de un servidor cambia, quizá porque se reinstaló el servidor o porque un atacante está suplantándolo, SSH rechaza la conexión y muestra una advertencia. Los administradores utilizan la autenticación de hosts basada en certificados para evitar decisiones de confianza TOFU a gran escala.

La autenticación mediante clave pública almacena la clave pública del usuario en ~/.ssh/authorized_keys en el servidor. Cuando el usuario se conecta, el servidor envía un desafío cifrado con la clave pública; solo quien posee la clave privada correspondiente puede responder correctamente y demostrar su identidad sin transmitir la clave privada ni una contraseña. Es más segura que las contraseñas porque las claves privadas nunca se envían por la red y no pueden ser objeto de phishing.

Hay tres familias de algoritmos de claves de SSH de uso habitual. Las claves RSA de 3072 o 4096 bits son compatibles con todos los servidores. ECDSA, que utiliza la curva NIST P-256, es más rápido que RSA con un nivel de seguridad equivalente, pero los parámetros de seguridad de P-256 han sido objeto de escrutinio. Ed25519, basado en el algoritmo de firma digital de curva de Edwards, es la recomendación moderna: claves de 256 bits rápidas y pequeñas, propiedades de seguridad sólidas y ausencia de preocupaciones por parámetros especiales.

Tatu Ylönen, un investigador finlandés de la Universidad Tecnológica de Helsinki, desarrolló SSH en 1995 después de que un ataque de captura de contraseñas en la red de su universidad expusiera cientos de credenciales. Eligió el puerto 22 porque estaba entre telnet (23) y ftp (21). SSH sustituyó a ambos protocolos inseguros. Ylönen fundó SSH Communications Security y posteriormente publicó SSH-2 como estándar abierto a través de la IETF. OpenSSH, la principal implementación libre, fue creada por el proyecto OpenBSD en 1999.

El agente SSH es un proceso en segundo plano que mantiene las claves privadas descifradas en memoria, lo que permite iniciar sesión una sola vez en varios servidores sin volver a introducir la frase de contraseña. La redirección del agente (opción -A) amplía esta capacidad al redirigir la conexión del agente a servidores remotos, permitiendo acceder en un salto a servidores internos. Sin embargo, la redirección del agente supone un riesgo de seguridad: un servidor remoto comprometido puede utilizar el agente redirigido para autenticarse como usted en otros servidores. Utilice ProxyJump en lugar de la redirección del agente.

Una configuración segura de SSH incluye deshabilitar el inicio de sesión de root (PermitRootLogin no), deshabilitar la autenticación mediante contraseña (PasswordAuthentication no) en favor del uso exclusivo de claves públicas, utilizar claves de host Ed25519, habilitar únicamente el protocolo SSH-2, configurar tiempos de espera para sesiones inactivas, restringir los usuarios permitidos con AllowUsers o AllowGroups y cambiar el puerto predeterminado como medida de ocultación para reducir el ruido de los escaneos automatizados. Fail2ban o herramientas similares bloquean las IP con repetidos intentos fallidos.

¿Por qué se considera que la autenticación de SSH mediante clave pública es más segura que la autenticación mediante contraseña?

SSH-2 sustituyó al defectuoso SSH-1 mediante capas separadas de transporte, autenticación y conexión. La capa de transporte negocia el cifrado y la integridad. La autenticación de usuarios admite contraseñas, claves públicas y GSSAPI. La verificación de la clave del host utiliza TOFU y known_hosts. Ed25519 es el algoritmo de claves recomendado. La redirección del agente supone un riesgo de seguridad; utilice ProxyJump en su lugar. El refuerzo de la seguridad incluye deshabilitar el inicio de sesión de root y la autenticación mediante contraseña.