Seguridad en servidores SSH: endurecimiento con claves Ed25519 y fail2ban

Introducción

SSH (Secure Shell) es la puerta de entrada principal a cualquier servidor Linux moderno. Su omnipresencia lo convierte en el vector de ataque más explotado en infraestructuras cloud y on-premise. Un servidor SSH mal configurado es una invitación abierta a ataques de fuerza bruta, exploits de protocolo y escalada de privilegios. Este artículo aborda dos pilares fundamentales para el endurecimiento de SSH: la adopción de claves Ed25519 como estándar criptográfico y la implementación de fail2ban como sistema de defensa proactivo contra intrusiones automatizadas.

Abordaremos la configuración desde cero, explicando la lógica subyacente de cada decisión técnica, incluyendo la desactivación de métodos obsoletos, la rotación de claves y la integración con sistemas de logging centralizado.

Fundamentos de Seguridad en SSH

El problema de la autenticación por contraseña

La autenticación mediante contraseña es inherentemente débil por varias razones:

Factor humano: contraseñas débiles, reutilizadas o almacenadas incorrectamente.
Ataques automatizados: bots que prueban combinaciones comunes a razón de miles por minuto.
Ausencia de trazabilidad: es difícil auditar quién accedió con qué credencial.
Sin resistencia a fuerza bruta distribuida: múltiples IPs atacando simultáneamente.

La solución definitiva es la autenticación basada en clave pública/privada, combinada con la desactivación total de la autenticación por contraseña.

Criptografía asimétrica moderna: RSA vs Ed25519

Durante años, RSA fue el estándar de facto. Sin embargo, presenta limitaciones que lo hacen menos óptimo en entornos modernos:

Característica	RSA (2048/4096 bits)	Ed25519
Algoritmo	Factorización de primos	Curva elíptica (Curve25519)
Tamaño de clave privada	~1.7 KB (4096 bits)	64 bytes
Velocidad de generación	Lenta (minutos en sistemas embebidos)	Instantánea
Resistencia cuántica	Baja (quiebra con Shor)	Mejor (aunque no completamente segura)
Compatibilidad	Universal (OpenSSH 2.0+)	OpenSSH 6.5+
Firma	Tamaño fijo (512 bytes)	Tamaño fijo (64 bytes)

Ed25519 ofrece seguridad equivalente a RSA 4096 bits con un rendimiento superior y menor huella de almacenamiento. Además, su implementación es resistente a ataques de canal lateral, un factor crítico en entornos cloud compartidos.

Paso 1: Generación de claves Ed25519

En el cliente (máquina local)

# Generar par de claves Ed25519
ssh-keygen -t ed25519 -a 100 -C "admin@servidor-produccion-$(date +%Y%m%d)"

# Opciones explicadas:
# -t ed25519: tipo de clave
# -a 100: número de rondas KDF (función de derivación de clave). 
#          100 es un balance entre seguridad y rendimiento.
# -C: comentario descriptivo para identificar la clave

# Verificar la clave generada
ls -la ~/.ssh/id_ed25519*

Nota técnica: El parámetro -a controla las iteraciones del algoritmo bcrypt usado para proteger la clave privada con contraseña. Valores más altos (100-1000) aumentan la resistencia contra ataques de fuerza bruta offline, a costa de tiempo de desbloqueo. Para servidores de alta criticidad, considere -a 200.

Configuración de passphrase obligatoria

# Si olvidó establecer passphrase durante la generación:
ssh-keygen -p -f ~/.ssh/id_ed25519

La passphrase protege la clave privada en reposo. Sin ella, cualquiera con acceso al archivo puede autenticarse. En entornos CI/CD, use agentes SSH con expiración forzada.

Paso 2: Configuración del servidor SSH

Copia segura de la clave pública

# Método recomendado: copia manual verificada
cat ~/.ssh/id_ed25519.pub | ssh usuario@servidor "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys && chmod 700 ~/.ssh"

# Alternativa automática (solo si confía en la integridad del canal):
ssh-copy-id -i ~/.ssh/id_ed25519.pub usuario@servidor

Hardening de `/etc/ssh/sshd_config`

A continuación, la configuración mínima para un servidor SSH endurecido:

# Respaldo de la configuración original
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date +%Y%m%d)

# Editar con privilegios
sudo nano /etc/ssh/sshd_config

Contenido crítico a establecer:

# Deshabilitar autenticación por contraseña

PasswordAuthentication no

ChallengeResponseAuthentication no

UsePAM no

# Forzar solo claves Ed25519 (deshabilitar RSA, DSA, ECDSA)

HostKeyAlgorithms ssh-ed25519

PubkeyAcceptedAlgorithms ssh-ed25519

KexAlgorithms curve25519-sha256@libssh.org

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com

MACs hmac-sha2-512-etm@openssh.com

# Restricciones de acceso

PermitRootLogin prohibit-password

MaxAuthTries 3

MaxSessions 5

ClientAliveInterval 300

ClientAliveCountMax 2

# Logging avanzado

LogLevel VERBOSE

SyslogFacility AUTH

Explicación de cada directiva:

PasswordAuthentication no: elimina el vector más común de ataque.
UsePAM no: evita vulnerabilidades en módulos PAM (ej: CVE-2024-3094 en xz).
HostKeyAlgorithms ssh-ed25519: solo acepta claves de host Ed25519.
KexAlgorithms curve25519-sha256@libssh.org: intercambio de claves seguro contra ataques de downgrade.
Ciphers chacha20-poly1305@openssh.com: cifrado autenticado con rendimiento superior en CPU sin AES-NI.
MACs hmac-sha2-512-etm@openssh.com: MAC Encrypt-then-MAC que previene ataques de padding oracle.
PermitRootLogin prohibit-password: permite root solo con clave, nunca con contraseña.
MaxAuthTries 3: limita intentos de autenticación antes de desconexión.
LogLevel VERBOSE: registra huellas dactilares de claves para auditoría forense.

Verificación de sintaxis y reinicio

# Validar configuración antes de aplicar
sudo sshd -t

# Si no hay errores, reiniciar servicio
sudo systemctl restart sshd

# Verificar que el servicio está escuchando
sudo ss -tlnp | grep :22

Paso 3: Implementación de fail2ban

fail2ban es un sistema de prevención de intrusiones que analiza logs y bloquea IPs maliciosas mediante reglas de iptables/nftables.

Instalación

# Debian/Ubuntu
sudo apt update && sudo apt install fail2ban -y

# RHEL/CentOS 8+
sudo dnf install epel-release -y
sudo dnf install fail2ban -y

# Verificar instalación
fail2ban-client --version

Configuración base

Crear archivo de configuración local (nunca modificar el archivo original jail.conf):

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Configuración global optimizada:

[DEFAULT]
# Tiempo de baneo: 1 hora (3600 segundos)
bantime = 3600

# Ventana de tiempo para contar fallos: 10 minutos
findtime = 600

# Número máximo de fallos antes del baneo
maxretry = 5

# Ignorar IPs internas y de confianza
ignoreip = 127.0.0.1/8 ::1 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

# Acción de baneo (usando nftables si está disponible)
banaction = nftables-multiport
banaction_allports = nftables-allports

# Notificaciones por correo (opcional, requiere MTA configurado)
action = %(action_mwl)s

Jail específico para SSH

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 86400  # 24 horas para SSH
findtime = 300   # 5 minutos

Importante: En sistemas que usan journald (systemd), la ruta de log puede ser diferente. Use journalctl -u sshd para verificar. En ese caso, configure:
logpath = %(journalctl)s
backend = systemd

Filtros personalizados para ataques avanzados

Crear filtro para detectar escaneo de puertos no estándar:

sudo nano /etc/fail2ban/filter.d/sshd-portscan.conf

Contenido:

[Definition]
failregex = ^%(__prefix_line)sFailed password for .* from <HOST> port \d+ ssh2$
            ^%(__prefix_line)sConnection closed by authenticating user .* <HOST> port \d+ \[preauth\]$
ignoreregex =

Paso 4: Configuración avanzada del cliente SSH

Archivo `~/.ssh/config` optimizado

# Configuración global

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
    TCPKeepAlive yes
    Compression yes
    CompressionLevel 6
    ControlMaster auto
    ControlPath ~/.ssh/controlmasters/%r@%h:%p
    ControlPersist 10m

# Host específico de producción

Host servidor-prod
    HostName 203.0.113.50
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    AddKeysToAgent yes
    ForwardAgent no
    PermitLocalCommand no

Explicación:

ControlMaster auto: reutiliza conexiones SSH existentes (ahorra handshakes).
ControlPersist 10m: mantiene el socket maestro 10 minutos tras cerrar sesión.
ForwardAgent no: previene forwarding de agente (riesgo de seguridad en hosts comprometidos).
IdentitiesOnly yes: fuerza usar solo la clave especificada, no todas las del agente.

Agente SSH con timeout forzado

# Iniciar agente con expiración
eval $(ssh-agent -t 3600)  # expira en 1 hora

# Agregar clave con confirmación requerida
ssh-add -t 3600 -c ~/.ssh/id_ed25519

El flag -c requiere confirmación del usuario antes de usar la clave, previniendo uso no autorizado por scripts maliciosos.

Paso 5: Monitoreo y respuesta a incidentes

Logs de autenticación

# Ver intentos de conexión fallidos en tiempo real
sudo journalctl -u sshd -f | grep -E "Failed password|Connection closed"

# Estadísticas de ataques por IP
sudo journalctl -u sshd | grep "Failed password" | awk '{print $11}' | sort | uniq -c | sort -nr | head -10

Integración con sistemas SIEM

Para entornos empresariales, configure fail2ban para enviar alertas a un SIEM via syslog:

sudo nano /etc/fail2ban/action.d/sendmail-siem.conf

[Definition]
actionban = logger -p auth.warning -t fail2ban "Banned IP: <ip> for service <name>"
actionunban = logger -p auth.notice -t fail2ban "Unbanned IP: <ip> for service <name>"

Rotación y expiración de claves

Implemente rotación automática de claves usando cron:

# Script de rotación (ejecutar mensualmente)
#!/bin/bash
# /usr/local/bin/rotate-ssh-keys.sh

BACKUP_DIR="/root/ssh-key-backup/$(date +%Y%m)"
mkdir -p "$BACKUP_DIR"

# Backup de claves antiguas
cp /etc/ssh/ssh_host_ed25519_key* "$BACKUP_DIR"

# Generar nuevas claves de host
ssh-keygen -t ed25519 -a 100 -f /etc/ssh/ssh_host_ed25519_key -N ""

# Forzar regeneración de claves de usuario (requiere script personalizado)
# ...

systemctl restart sshd

Verificación y pruebas de penetración

Escaneo de configuración SSH

# Usar ssh-audit para evaluar la seguridad
pip install ssh-audit
ssh-audit servidor-prod

# Salida esperada:
# [info] CVE-2024-6387: Not vulnerable (OpenSSH 9.8p1)
# [info] Ciphers: chacha20-poly1305@openssh.com (200/100)
# [info] Kex: curve25519-sha256@libssh.org (200/100)

Prueba de fuerza bruta controlada

# Simular ataque con hydra (solo en entorno de pruebas)
hydra -l admin -P rockyou.txt -t 4 ssh://203.0.113.50

# Verificar que fail2ban bloquea tras 3 intentos
sudo fail2ban-client status sshd
# Status for the jail: sshd
# |- Filter
# |  |- Currently failed: 0
# |  |- Total failed:     3
# |- Actions
#    |- Currently banned: 1
#    |- Total banned:     1

Consideraciones finales y checklist de endurecimiento

Componente	Acción	Verificación
Claves	Generar Ed25519 con passphrase	`ssh-keygen -l -f ~/.ssh/id_ed25519.pub`
Servidor	Deshabilitar contraseñas	`grep PasswordAuthentication /etc/ssh/sshd_config`
fail2ban	Jail SSH activo	`fail2ban-client status sshd`
Logs	VERBOSE habilitado	`grep LogLevel /etc/ssh/sshd_config`
Firewall	Puerto 22 restringido a IPs confiables	`iptables -L INPUT -n \| grep :22`
Actualizaciones	OpenSSH >= 9.8	`sshd -V \| grep OpenSSH`
2FA	Google Authenticator + PAM (opcional)	`grep AuthenticationMethods /etc/ssh/sshd_config`

Advertencia crítica: Antes de cerrar su sesión SSH actual, siempre abra una segunda conexión paralela para probar la nueva configuración. Un error en sshd_config puede dejarlo fuera del servidor de forma permanente. Use screen o tmux para mantener una sesión de respaldo mientras realiza cambios.

La combinación de claves Ed25519 con fail2ban no es una solución completa, sino la base de una estrategia de defensa en profundidad. Complemente con autenticación multifactor (TOTP vía libpam-google-authenticator), restricciones por firewall a nivel de red (whitelist de IPs), y monitoreo continuo de logs. En entornos críticos, considere soluciones como Teleport o Boundary que abstraen completamente el acceso SSH tradicional.