Cómo configurar SSH seguro en VPS: guía práctica

Para configurar SSH seguro en un VPS, el mínimo indispensable es: deshabilitar el acceso como root, usar autenticación por clave pública y cambiar el puerto predeterminado. Sin esas tres medidas, cualquier servidor expuesto a Internet sufre ataques de fuerza bruta en minutos.

Esta guía cubre cada paso con los comandos exactos para un servidor Linux (Ubuntu/Debian o CentOS/AlmaLinux). Al terminarla tendrás un acceso SSH endurecido que resiste los ataques automatizados más comunes.

Por qué el SSH sin configurar es el principal vector de ataque

SSH escucha en el puerto 22 por defecto. Los bots escanean Internet de forma continua buscando ese puerto abierto y, una vez que lo encuentran, lanzan ataques de diccionario contra el usuario root. Un VPS recién instalado puede recibir miles de intentos de login en sus primeras horas.

El problema no es el protocolo SSH en sí, que es criptográficamente sólido. El problema es la configuración de fábrica, diseñada para conveniencia, no para producción.

Paso 1: Crea un par de claves SSH (en tu máquina local)

Antes de tocar el servidor, genera las claves en tu computadora:

# ED25519 es moderno y más corto; RSA 4096 también es válido
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/mi_vps_ed25519

Elige una passphrase robusta cuando el comando la pida. La clave privada nunca sale de tu máquina; solo subirás la clave pública (.pub) al servidor.

Copia la clave pública al VPS:

ssh-copy-id -i ~/.ssh/mi_vps_ed25519.pub usuario@IP_DEL_VPS

Verifica que puedes entrar con la clave antes de hacer cualquier cambio adicional. Si algo sale mal después tendrás una sesión abierta para corregirlo.

Paso 2: Edita /etc/ssh/sshd_config

Abre el archivo de configuración del daemon SSH:

sudo nano /etc/ssh/sshd_config

Aplica estas directivas clave:

Directiva	Valor recomendado	Por qué
`Port`	Un número entre 1024 y 65535 (p. ej. 2222)	Elimina el 99 % del ruido de bots que solo escanean el 22
`PermitRootLogin`	`no`	El root es el objetivo principal de fuerza bruta
`PasswordAuthentication`	`no`	Sin contraseña, la fuerza bruta queda sin efecto
`PubkeyAuthentication`	`yes`	Habilita explícitamente las claves
`AuthorizedKeysFile`	`.ssh/authorized_keys`	Ruta estándar; confirma que no fue comentada
`MaxAuthTries`	`3`	Limita intentos fallidos por conexión
`LoginGraceTime`	`30`	30 segundos para autenticarse o se cierra la conexión
`AllowUsers`	`tu_usuario`	Solo este usuario puede usar SSH; los demás, negados
`X11Forwarding`	`no`	Reduce superficie de ataque si no necesitas GUI remota
`UseDNS`	`no`	Acelera el login al evitar resolución DNS inversa

Guarda el archivo y verifica que no tiene errores de sintaxis antes de reiniciar:

sudo sshd -t

Si el comando no devuelve nada, la sintaxis es correcta. Reinicia el servicio:

# Ubuntu/Debian
sudo systemctl restart ssh

# CentOS/AlmaLinux
sudo systemctl restart sshd

Importante: abre una segunda terminal y conéctate al nuevo puerto antes de cerrar la sesión actual. Así confirmas que todo funciona sin quedarte bloqueado.

Paso 3: Configura el firewall para el nuevo puerto

Si usas UFW (Ubuntu/Debian):

sudo ufw allow 2222/tcp comment "SSH personalizado"
sudo ufw deny 22/tcp
sudo ufw reload

Si usas firewalld (CentOS/AlmaLinux):

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Recuerda también actualizar las reglas del panel de tu proveedor de VPS si tiene un firewall de red separado (muy común en DigitalOcean, Hetzner, Linode, etc.).

Paso 4: Protección adicional con Fail2Ban

Aunque ya deshabilitaste la autenticación por contraseña, instalar Fail2Ban añade una capa de defensa que bloquea IPs con demasiados intentos fallidos:

# Ubuntu/Debian
sudo apt install fail2ban -y

# CentOS/AlmaLinux
sudo dnf install fail2ban -y

Crea un archivo de configuración local para no perder cambios al actualizar:

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

Edita /etc/fail2ban/jail.local y ajusta la sección [sshd]:

[sshd]
enabled  = true
port     = 2222
maxretry = 5
bantime  = 1h
findtime = 10m

sudo systemctl enable --now fail2ban

Con esto, cualquier IP que falle 5 veces en 10 minutos queda bloqueada 1 hora automáticamente.

Buenas prácticas adicionales

Rota tus claves periódicamente: si sospechas que una clave privada fue comprometida, genera un nuevo par y elimina la clave antigua de ~/.ssh/authorized_keys.
Usa SSH Agent Forwarding con precaución: solo habilita ForwardAgent yes cuando realmente saltes de servidor a servidor; en cualquier otro caso, déjalo desactivado.
Mantén OpenSSH actualizado: ejecuta sudo apt update && sudo apt upgrade openssh-server regularmente. Las vulnerabilidades como la CVE-2024-6387 (regreSSHion) se parchean rápido pero solo si actualizas.
Revisa los logs de autenticación: sudo journalctl -u ssh --since today o /var/log/auth.log para detectar patrones anómalos.
Considera 2FA con TOTP: el módulo libpam-google-authenticator añade un segundo factor sin romper el flujo de clave pública.

Si gestionas varios servidores, también puedes explorar más recursos en el catálogo de guías sobre servidores VPS donde encontrarás artículos sobre firewall, monitoreo y optimización.

Conclusiones clave

Deshabilitar el login de root y la autenticación por contraseña son los dos cambios con mayor impacto inmediato.
Usar claves ED25519 o RSA de 4096 bits hace la autenticación criptográficamente resistente a fuerza bruta.
Cambiar el puerto 22 por uno personalizado reduce drásticamente el ruido en los logs.
Fail2Ban bloquea IPs maliciosas automáticamente aunque queden resquicios de ataque.
Siempre verifica que la nueva configuración funciona en una segunda terminal antes de cerrar la sesión activa.

¿Necesitas ayuda para asegurar tu servidor o buscas un VPS configurado con buenas prácticas desde el primer día? Contáctanos en elenlace.com — nuestro equipo te acompaña en cada paso del proceso.

Preguntas frecuentes

¿Es obligatorio cambiar el puerto SSH?

No es obligatorio, pero sí muy recomendable. Cambiar el puerto 22 por uno personalizado elimina el tráfico de bots automatizados que solo escanean el puerto estándar. En servidores de prueba puede ser prescindible; en producción vale siempre la pena.

¿Puedo usar claves RSA en lugar de ED25519?

Sí. RSA con 4096 bits es perfectamente seguro hoy. ED25519 es preferible porque las claves son más cortas, las operaciones más rápidas y el algoritmo es más moderno. Si tu cliente SSH es muy antiguo y no soporta ED25519, usa RSA-4096.

¿Qué hago si me quedo sin acceso SSH por error de configuración?

La mayoría de los proveedores de VPS ofrecen una consola de emergencia desde el panel web (KVM o VNC). Úsala para corregir el archivo sshd_config y reiniciar el servicio. Es la razón por la que siempre debes mantener la sesión original abierta mientras pruebas los cambios.

¿Fail2Ban protege si deshabilito las contraseñas?

Sí, de otras formas. Aunque sin contraseñas la fuerza bruta directa no sirve, Fail2Ban puede bloquear intentos de enumeración de usuarios, escaneos de versión o ataques a otros servicios del mismo servidor (Apache, FTP, etc.). Instalarlo siempre suma.

¿Prefieres que lo hagamos por ti? En El Enlace resolvemos hosting y desarrollo web profesional.

Recursos útiles

Otros proveedores y guías que vale la pena comparar: