Hardening SSH en 2026: 10 cambios que deberías hacer hoy

Tu servidor SSH es probablemente la puerta de entrada más importante a tu infraestructura. En este post vas a aprender los 10 cambios concretos que deberías hacer HOY para asegurarlo, desde lo más básico hasta técnicas avanzadas que usan los profesionales.

Por qué importa SSH seguro

SSH es el protocolo que usas para entrar a tus servers. Si alguien no autorizado entra por SSH, tiene control total de tu server. Eso significa acceso a tus archivos, a tus bases de datos, a tus secrets, y la posibilidad de pivotar a otros servers de tu red.

Los ataques automatizados a SSH son constantes. Los bots prueban combinaciones de usuario/contraseña 24/7. Si tienes el puerto 22 abierto a internet, en algún momento van a entrar si no sigues buenas prácticas.

Afortunadamente, asegurar SSH es relativamente simple. Los 10 cambios que siguen te protegen del 99% de los ataques automatizados.

1. Deshabilitar login por password

El primer cambio y el más importante. Solo claves SSH, nada de contraseñas.

Editá /etc/ssh/sshd_config:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no

Reiniciá el servicio:

sudo systemctl restart sshd

Después de esto, solo puedes entrar con una clave SSH. Las contraseñas adivinadas quedan descartadas como vector de ataque. Si todavía no tienes una clave SSH en tu laptop, generá una antes de aplicar este cambio:

ssh-keygen -t ed25519
ssh-copy-id usuario@servidor

Si no generas la clave primero, te vas a quedar afuera del server.

2. Cambiar el puerto por defecto

El puerto 22 es el más atacado del mundo. Cambialo:

Port 2222

No es seguridad por oscuridad perfecta, pero filtra el 90% de los scripts automatizados que solo escanean puerto 22. Es un cambio simple que reduce dramáticamente tu superficie de ataque.

Si tienes un firewall, también puedes limit access al puerto nuevo solo desde IPs conocidas.

3. Deshabilitar login root

No te loguees como root directamente. usa un usuario normal y sudo cuando necesites privilegios:

PermitRootLogin no

Esto previene que un atacante con una clave comprometida tenga acceso root directo. Aunque alguien entre como tu usuario, todavía necesita escalar privilegios.

4. Limitar usuarios que pueden entrar

En lugar de permitir cualquier usuario del sistema a entrar por SSH, especificá cuáles pueden:

AllowUsers roger patricia deploy

Ahora si un atacante tiene una clave de un usuario que no está en esta lista, simplemente no puede entrar.

5. SSH 2 ya es el único protocolo soportado

No tienes que hacer nada: OpenSSH 2.0+ (año 2000) ya solo soporta SSH 2. SSH 1 quedó deprecado y eliminado hace más de dos décadas. Si ves un tutorial viejo que dice Protocol 2, ignorá esa directiva — ya no existe en sshd_config de OpenSSH actual y rompe la validación.

6. Configurar timeout para sesiones zombie

Si se corta la conexión a internet, tu sesión SSH puede quedar abierta indefinidamente. Eso es un riesgo de seguridad. configura timeouts agresivos:

ClientAliveInterval 300
ClientAliveCountMax 2

Esto cierra sesiones inactivas después de 10 minutos. Ajustá según tu necesidad: si trabajas con conexiones lentas, subí los valores.

7. Deshabilitar TCP forwarding si no lo necesitas

SSH puede tunelizar tráfico TCP. Es muy útil pero también es un vector de escape si alguien compromete tu sesión:

AllowTcpForwarding no
AllowAgentForwarding no
X11Forwarding no

Si necesitas SSH tunneling, dejá AllowTcpForwarding yes pero nunca lo uses desde servers expuestos a internet directamente.

8. Limitar intentos con MaxAuthTries

El default en muchas distros es 6 intentos. Bajalo a 3:

MaxAuthTries 3

Combinado con fail2ban (ver siguiente), bloqueás ataques de fuerza bruta efectivamente.

9. Usar claves ED25519 en lugar de RSA

ED25519 es el algoritmo más moderno para claves SSH. Es más rápido, las claves son más cortas (32 bytes vs 256+ para RSA), y es criptográficamente superior:

ssh-keygen -t ed25519 -a 100

El parámetro -a 100 hace 100 rounds de KDF (Key Derivation Function), lo que hace más difícil brute-forcear la passphrase de la clave si te la roban.

No generes nuevas claves RSA. Si tienes claves RSA existentes que funcionan, no hace falta migrar, pero para claves nuevas siempre ED25519.

10. Activar claves SSH con FIDO2 (YubiKey / Titan Key)

Con OpenSSH 8.2+ puedes generar la clave SSH directamente en el hardware físico (YubiKey, Titan Key, etc.). Cuando entrás, el server exige que toques la clave. Aunque alguien robe tu laptop, no entra sin el device físico.

Generación de la clave (con residente y verificación obligatoria):

ssh-keygen -t ed25519-sk -O resident -O verify-required

Si tu YubiKey no soporta ed25519-sk, prueba:

ssh-keygen -t ecdsa-sk -O resident -O verify-required

Copiá la clave pública al server:

ssh-copy-id usuario@servidor

Y en el server, en ~/.ssh/authorized_keys, asegurate de que la línea empiece con ssh-ed25519 AAAA... (o ecdsa-sha2-nistp256). No hace falta tocar sshd_config: el requerimiento del token físico lo lleva la propia clave sk-, no la directiva.

Para usarla desde el cliente necesitas un ssh-agent cargado con la clave residente:

ssh-add -K   # carga las claves sk residentes en el agent estándar

No hay que apuntar a ningún IdentityAgent custom: ssh-agent estándar lo maneja vía SSH_AUTH_SOCK, que ya está seteado cuando corres eval $(ssh-agent).

Configuración completa recomendada

Juntando todo, tu sshd_config debería verse así:

Port 2222
PermitRootLogin no
AllowUsers roger patricia deploy
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PubkeyAuth yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowTcpForwarding no
X11Forwarding no

Nota: sshd_config de OpenSSH actual no soporta la directiva Protocol 2 (ya es el default) ni la línea AuthenticationMethods publickey,keyboard-interactive sin un backend PAM con TOTP configurado — esas dos directivas se omitieron porque romperían la autenticación. Para 2FA real usa claves FIDO2 (sección 10).

Reiniciá:

sudo systemctl restart sshd

Verificar que todo funciona

Desde otra terminal, intentá entrar al server. Si funciona, perfecto. Si no, tienes que entrar desde la consola física o KVM del provider para arreglarlo.

ssh -p 2222 -o PasswordAuthentication=no roger@servidor

El -o PasswordAuthentication=no es para forzar el uso de clave y verificar que el server no está aceptando passwords.

Logging y monitoreo

activa el log detallado de SSH para detectar intentos sospechosos:

LogLevel VERBOSE

Después puedes monitorear con journalctl -u sshd o enviar logs a un SIEM como Splunk o Elastic.

Conclusión

Estos 10 cambios llevan unos 30 minutos y te protegen del 99% de los ataques automatizados. Si tienes un server expuesto a internet, hacelos ya, en orden.

El cambio más importante es deshabilitar password login. Eso solo elimina el 90% del riesgo. Los demás cambios son capas adicionales de defensa.

Si tienes dudas sobre algún paso, prueba los cambios en una VM local antes de aplicarlos a producción. Mejor un test que un server bloqueado.

---

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux