SECURITY 15 min

Hardening y Gestión de Servidores SSH: De Ed25519 y FIDO2 a Zero Trust

Guía exhaustiva para blindar servidores SSH en Linux: migración de RSA a Ed25519 y llaves de hardware FIDO2, directivas críticas de sshd_config, Fail2ban y bastiones ProxyJump.

Escrito por Samir El Azem Crovetto • Senior Backend Engineer & DevSecOps

La Realidad de la Administración Remota en Linux

En la administración de infraestructuras Linux y entornos cloud, el protocolo SSH (Secure Shell / OpenSSH) sigue siendo tanto la columna vertebral de la gestión remota como uno de los objetivos más expuestos y asediados de Internet.

Basta con desplegar una máquina virtual con el puerto 22 accesible públicamente durante diez minutos para comprobar en /var/log/auth.log cómo decenas de bots automatizados lanzan ataques de diccionario incesantes. Sin embargo, en 2026 el peligro crítico rara vez procede de un ataque de fuerza bruta sobre contraseñas débiles; los riesgos más graves surgen de configuraciones permisivas heredadas: uso de algoritmos criptográficos obsoletos (como RSA con firmas SHA-1), dispersión descontrolada de archivos authorized_keys, reenvío peligroso del agente SSH (ForwardAgent yes) y ausencia de autenticación física resistente al phishing.

En esta guía técnica abordamos una metodología rigurosa de hardening integral de SSH para entornos de producción: desde la generación de claves criptográficas modernas (Ed25519 y llaves de hardware FIDO2/U2F) hasta la configuración blindada de sshd_config, defensas activas con Fail2ban y arquitecturas Zero Trust basadas en bastiones y autoridades certificadoras (SSH CA).

Arquitectura de Acceso Seguro SSH: Flujo Criptográfico y Bastión

Antes de modificar directivas de configuración, es fundamental establecer un modelo de aislamiento perimetral. En una arquitectura de red segura, los nodos de cómputo internos o clústeres de Kubernetes nunca deben tener puertos SSH expuestos directamente a redes públicas.

El siguiente diagrama ilustra el flujo de autenticación endurecido, integrando tokens de hardware FIDO2, anclaje criptográfico y un host bastión (Jump Host):

flowchart TD
    subgraph Workstation ["Puesto de Trabajo del Ingeniero"]
        A[Ingeniero / Terminal Local] --> B[Clave Criptografica Ed25519-SK<br/>Token Hardware FIDO2 / YubiKey]
        B --> C[ssh -J bastion.empresa.com<br/>ProxyJump Directo]
    end

    subgraph Perimeter ["Zona Perimetral DMZ"]
        C --> D[Bastion Host / Jump Server<br/>OpenSSH Endurecido + MFA]
        D --> E[Firewall nftables / Fail2ban<br/>Jailing Automatico por IP]
    end

    subgraph Internal_Network ["Red Privada / VPC Segura"]
        E --> F[Nodo de Servidor Interno<br/>sshd_config Hardened]
        F --> G[Verificacion de Firma Criptografica<br/>authorized_keys o SSH CA]
        G --> H[Shell Aislada sin Privilegios<br/>sudo con MFA obligatorio]
    end

    classDef stage fill:#1e1e2e,stroke:#6366f1,stroke-width:2px,color:#cdd6f4;
    class Workstation,Perimeter,Internal_Network stage;

1. Criptografía Moderna: El Fin de RSA y el Salto a Ed25519 y FIDO2

Uno de los hallazgos más habituales en revisiones de seguridad de infraestructura es la presencia de claves RSA heredadas de 1024 o 2048 bits, o claves generadas con parámetros débiles sin frase de paso.

OpenSSH deshabilitó por defecto las firmas con hash SHA-1 (ssh-rsa) a partir de la versión 8.8 debido a su debilidad matemática demostrada. Hoy en día, la política criptográfica debe ser estricta:

Algoritmo Nivel de Seguridad Longitud Clave Recomendación en Producción
RSA (1024 / 2048 bits) Roto / Débil Larga Terminantemente Prohibido
RSA (4096 bits) Aceptable legacy Muy larga (4096) Solo por compatibilidad extrema con sistemas legacy
ECDSA (P-256 / P-384) Cuestionado (curvas NIST) Corta No recomendado (dudas sobre constantes Dual_EC)
Ed25519 (Curva Edwards) Óptimo (128-bit security) Muy corta (256 bits) Estándar Recomendado por Defecto
Ed25519-SK (FIDO2) Máximo (Anti-Phishing) Hardware Token Estándar Oro para Accesos Críticos

Generación de Claves Ed25519 con Máxima Derivación de Clave (KDF)

Al generar una clave Ed25519 en la máquina local, conviene utilizar la bandera -a para forzar un número elevado de rondas de derivación de clave con bcrypt (KDF), ralentizando exponencialmente cualquier intento de descifrado por fuerza bruta en caso de filtración de la clave privada:

# Generacion de clave Ed25519 con 100 rondas de derivacion bcrypt
ssh-keygen -t ed25519 -a 100 -C "admin@empresa.com" -f ~/.ssh/id_ed25519_production

Regla de Oro: Introduce siempre una frase de paso (passphrase) robusta. Una clave privada sin frase de paso es una credencial en texto plano esperando a ser exfiltrada por cualquier malware local.

El Estándar Oro: Claves Respaldadas por Hardware FIDO2 (Ed25519-SK)

Para credenciales con acceso a entornos de producción o infraestructura crítica, se recomienda emplear claves FIDO2 respaldadas por tokens físicos (como YubiKey o Nitrokey). La clave privada física jamás sale del chip de seguridad; solo reside en el disco un key handle (descriptor de clave):

# Generar clave vinculada a token hardware FIDO2/U2F con presencia obligatoria
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "yubikey-fido2-admin"

Con esta directiva, cualquier intento de inicio de sesión SSH exige tocar físicamente la llave de seguridad (user presence) e introducir el PIN de la llave (user verification), neutralizando por completo el phishing y el robo de credenciales por software.

2. Hardening Riguroso de sshd_config: Baseline de Producción

El archivo de configuración del demonio OpenSSH (/etc/ssh/sshd_config) viene configurado en la mayoría de distribuciones Linux para priorizar la compatibilidad hacia atrás. En un entorno corporativo, debemos priorizar la seguridad por defecto.

En lugar de editar directamente el archivo monolítico, en las distribuciones modernas (Ubuntu 22.04+, Debian 12+, RHEL 9+) la mejor práctica consiste en modularizar la configuración mediante /etc/ssh/sshd_config.d/99-hardened.conf. Esto evita que las actualizaciones de paquetes del sistema sobrescriban las directivas establecidas.

A continuación se presenta una configuración de referencia endurecida para producción:

# /etc/ssh/sshd_config.d/99-hardened.conf
# Baseline de Seguridad Estricta OpenSSH - SecDevOps Standard

# 1. Autenticacion e Identidad
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
PubkeyAuthentication yes
AuthenticationMethods publickey

# 2. Control de Acceso y Sesion
MaxAuthTries 3
LoginGraceTime 20
MaxSessions 4
ClientAliveInterval 300
ClientAliveCountMax 2

# 3. Restriccion de Usuarios y Grupos Autorizados
# Solo permitimos la entrada a usuarios del grupo ssh-users
AllowGroups ssh-users

# 4. Deshabilitacion de Vectores de Fuga y Forwarding Peligroso
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
GatewayPorts no
PermitUserEnvironment no

# 5. Algoritmos Criptograficos Modernos (Ciphers, MACs, Kex)
# Desactivamos ciphers CBC, SHA-1 y algoritmos debiles
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# 6. Logging y Auditoria Forense
LogLevel VERBOSE
SyslogFacility AUTH

Por qué importan estas directivas específicas:

  • PermitRootLogin no: Obliga a cualquier administrador a autenticarse primero con su usuario nominal individual y utilizar sudo trazable para tareas privilegiadas.
  • AllowAgentForwarding no: Si un atacante compromete un servidor intermedio donde te has conectado con ssh -A (Agent Forwarding), puede secuestrar el socket local de ssh-agent para saltar a otros servidores sin conocer tu clave privada. Deshabilitar el forwarding del agente rompe este vector lateral.
  • KexAlgorithms con sntrup761x25519-sha512: Introduce criptografía post-cuántica híbrida (NTRU Prime + X25519) soportada de forma nativa en OpenSSH 9.0+, protegiendo las sesiones contra ataques de tipo Harvest Now, Decrypt Later ante futuros ordenadores cuánticos.

Antes de reiniciar el servicio SSH, valida siempre la sintaxis de la configuración para evitar bloqueos accidentales fuera del servidor:

# Validar sintaxis antes de reiniciar
sudo sshd -t

# Si no arroja ningun error, reiniciar el demonio
sudo systemctl restart sshd

3. Protección Dinámica Perimetral: Fail2ban y nftables

Aunque se deshabiliten las contraseñas, los escáneres masivos continuarán consumiendo ciclos de CPU y saturando los logs del sistema. Fail2ban monitoriza en tiempo real los registros del sistema (/var/log/auth.log o el diario de systemd) y genera bloqueos automáticos en el firewall cuando detecta anomalías.

Configuración recomendada en /etc/fail2ban/jail.d/sshd-hardened.local:

# /etc/fail2ban/jail.d/sshd-hardened.local
[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 3
findtime = 10m
bantime = 24h
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 60d
action = nftables-multiport[name=sshd, port="ssh", protocol=tcp]

Con esta configuración:

  1. Cualquier IP que falle 3 intentos en 10 minutos queda expulsada durante 24 horas.
  2. Si la misma IP reincide, la directiva bantime.increment = true duplica exponencialmente el castigo hasta un máximo de 60 días.
  3. Se comunica directamente con nftables en el kernel Linux para un filtrado de paquetes de alto rendimiento sin sobrecarga en espacio de usuario.

4. Arquitectura de Salto Seguro: Bastión con ProxyJump

En arquitecturas empresariales y proveedores cloud como AWS, Google Cloud o Azure, los servidores de bases de datos o aplicaciones nunca deben tener direcciones IP públicas. El acceso administrativo se canaliza a través de un Host Bastión endurecido.

La práctica obsoleta consistía en conectarse al bastión con ssh -A (Agent Forwarding) y desde allí lanzar otro SSH al servidor interno, exponiendo el agente SSH a cualquier atacante con privilegios en el bastión.

La solución moderna y segura es utilizar ProxyJump:

Configuración en el archivo local ~/.ssh/config:

# ~/.ssh/config en la maquina del administrador

# Configuracion global de seguridad
Host *
    HashKnownHosts yes
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 3

# Servidor Bastion Perimetral (Unico con IP publica)
Host bastion-prod
    HostName bastion.empresa.com
    User admin
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_production

# Servidor de Base de Datos Privado (IP interna 10.0.2.15)
Host db-prod-internal
    HostName 10.0.2.15
    User dbadmin
    ProxyJump bastion-prod
    IdentityFile ~/.ssh/id_ed25519_internal

Para conectarse al servidor interno en la red privada, simplemente se ejecuta:

ssh db-prod-internal

OpenSSH establece un túnel cifrado extremo a extremo a través del bastión de forma completamente transparente. El bastión actúa únicamente como un relé de sockets TCP a nivel de transporte, sin tener acceso en ningún momento a la sesión cifrada SSH ni a las claves privadas.

5. El Siguiente Nivel: Autoridades Certificadoras SSH (SSH CA)

En organizaciones con decenas de desarrolladores y cientos de servidores, el modelo tradicional de copiar claves públicas en archivos authorized_keys se vuelve insostenible y arriesgado:

  • No existe un mecanismo ágil para revocar accesos cuando un ingeniero abandona el equipo.
  • No hay fecha de caducidad: las claves permanecen en servidores olvidados durante años.

La solución empresarial recomendada es implementar una SSH Certificate Authority (SSH CA):

  1. Se crea una clave de Autoridad Certificadora protegida en un módulo HSM o servidor aislado.
  2. Los servidores Linux confían en la CA mediante una única directiva en su sshd_config:

TrustedUserCAKeys /etc/ssh/ssh_ca.pub

  1. Cuando un ingeniero necesita acceso, se le expide un certificado criptográfico temporal (por ejemplo, con una validez de 8 horas) firmado por la CA que especifica sus permisos y grupos.
  2. Una vez transcurridas las 8 horas, el certificado expira automáticamente sin necesidad de tocar ningún servidor.

Este enfoque se alinea directamente con el principio de mínimo privilegio y arquitecturas Zero Trust, tal como analizamos en nuestra guía sobre Autenticación vs. Autorización en Sistemas Web y en las prácticas de DevSecOps y pipelines de seguridad.

Conclusión y Checklist Operativo

El endurecimiento de SSH no es una tarea puntual: es una disciplina continua de control de accesos, higiene criptográfica y defensa en profundidad.

Si necesitas auditar la seguridad perimetral de tus servidores, implementar arquitecturas de acceso con llaves hardware FIDO2 o diseñar infraestructuras Zero Trust para tu organización, puedes consultar mis Servicios de Ciberseguridad y Consultoría o contactar directamente conmigo a través de mi perfil Sobre mí.