Cómo reforzar SSH en un VPS paso a paso

Por qué SSH es lo primero que debe reforzarse

SSH permite controlar el servidor, por lo que es la cerradura que todos los atacantes intentan abrir primero. En cuanto un VPS se conecta a Internet, los escáneres empiezan a probar nombres de usuario y contraseñas en el puerto 22. Puede observarlo en los registros en cuestión de minutos. Reforzar SSH consiste en eliminar lo que los atacantes pueden adivinar: desactivar por completo el inicio de sesión mediante contraseña, desactivar el inicio de sesión de root y permitir únicamente claves criptográficas. Después de hacerlo, los intentos constantes ya no pueden tener éxito porque no hay ninguna contraseña que encontrar.

Esto presupone que SSH ya funciona. Si puede iniciar sesión, puede reforzarlo. Siga los pasos en orden y mantenga abierta la sesión actual hasta que una sesión nueva funcione. Así, un error no le impedirá acceder al servidor.

Paso 1: Asegúrese de que la autenticación mediante claves funciona primero

La autenticación mediante claves sustituye una contraseña por un par de claves: una clave privada que permanece en su equipo y una clave pública que copia en el servidor. El servidor comprueba que tiene la clave privada sin que esta salga de su equipo. Antes de deshabilitar las contraseñas, confirme que las claves funcionan. De lo contrario, podría bloquearse el acceso.

En su propio equipo, cree una clave si no tiene ninguna:

ssh-keygen -t ed25519

Copie la parte pública al servidor:

ssh-copy-id user@your-server

A continuación, abra una nueva sesión SSH. Si puede iniciar sesión sin que se le solicite una contraseña, la clave funciona y puede deshabilitar las contraseñas de forma segura. Si el acceso se detiene con Permission denied (publickey), ese error puede ocultar cinco fallos diferentes, y la salida de ssh -v le indica cuál tiene antes de cambiar cualquier otra cosa. Si las claves son nuevas para usted o usa más de un equipo, conceptos básicos de la gestión de claves SSH explica el modelo completo: una clave por dispositivo, los permisos que exige sshd y cómo revocar una clave si se pierde un portátil.

Paso 2: Refuerce sshd con un archivo drop-in

No edite /etc/ssh/sshd_config directamente. Ubuntu 24.04 lee los archivos drop-in desde /etc/ssh/sshd_config.d/. Un archivo pequeño en ese directorio es más limpio, sobrevive a las actualizaciones de paquetes y se puede eliminar fácilmente si algo sale mal. El nombre importa: sshd conserva el primer valor que lee para cada ajuste, y las imágenes de Ubuntu para la nube incluyen 50-cloud-init.conf con PasswordAuthentication yes en este directorio. Asigne a su archivo el nombre 00- para que se ordene antes que ese archivo y prevalezca. Un archivo 99- pierde silenciosamente. Cree uno:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Añada lo siguiente:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

Cada línea cierra una vía de acceso. PasswordAuthentication no es la más importante: con las contraseñas desactivadas, un ataque de fuerza bruta no tiene ninguna contraseña que probar. KbdInteractiveAuthentication no cierra una segunda vía basada en contraseñas. PermitRootLogin no significa que un atacante debe conocer su nombre de usuario y tener su clave, en lugar de dirigirse sólo a la única cuenta, root, que existe en todos los equipos.

Paso 3: Compruebe la configuración y recargue el servicio

Compruebe si hay errores en la configuración antes de aplicarla. Así, un error tipográfico no puede dejar el servicio fuera de servicio:

sudo sshd -t

Si no muestra nada, la configuración es válida. Recargue SSH:

sudo systemctl reload ssh

Después, compruebe la configuración que usa realmente sshd. Así detectará si otro archivo ha tenido prioridad sobre un archivo drop-in:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Ambos comandos deben mostrar no. Ahora, sin cerrar la sesión actual, abra una sesión completamente nueva desde otro terminal. Si inicia sesión con su clave, ha terminado. Si algo falla, la primera sesión seguirá abierta para que pueda corregirlo. Esta sesión simultánea es la red de seguridad. No la omita.

Paso 4: El puerto no estándar opcional

Cambiar SSH del puerto 22 a otro como 2222 no lo hace más seguro en términos reales, porque un atacante decidido analiza todos los puertos. Lo que sí hace es reducir el ruido de los registros, ya que la mayoría de los escáneres automatizados sólo prueban el puerto 22. Si lo necesita, añada Port 2222 al archivo drop-in, permita primero el nuevo puerto en el firewall, ejecute después sudo systemctl daemon-reload && sudo systemctl restart ssh.socket y conéctese mediante ssh -p 2222. En Ubuntu 24.04, ssh.socket controla el puerto de escucha, por lo que un reload ssh simple mantiene sshd en el puerto 22; para aplicar el nuevo puerto debe reiniciar el socket. Considérelo una medida de orden, no de protección.

Paso 5: Añada las defensas adicionales

Las claves SSH reforzadas son la base. Sobre ellas se añaden dos capas más.

Fail2ban monitoriza los registros y bloquea las direcciones que siguen fallando. Esto reduce el ruido de los escáneres y las expulsa pronto. Se combina de forma natural con la autenticación exclusiva mediante claves: consulte Fail2ban en Ubuntu para detener los ataques contra SSH.

Una medida aún más segura consiste en mantener SSH completamente fuera de Internet pública. Si coloca SSH detrás de una VPN WireGuard y limita el puerto 22 al túnel, nadie fuera de la VPN puede llegar a él. Los intentos de fuerza bruta dejan de ser posibles, en lugar de limitarse a ser más difíciles. Todo esto presupone un firewall subyacente con denegación predeterminada, como la configuración de UFW en el VPS.

SSH es sólo un elemento de una lista de comprobación más amplia: los primeros 10 minutos en un VPS nuevo ordenan los pasos, y las actualizaciones de seguridad automáticas en Ubuntu mantienen el sistema actualizado después. Cerrar esa puerta no protege los servicios que están detrás. Si este mismo VPS ejecuta un gestor de contraseñas, una revisión de seguridad de Vaultwarden cubre los dos aspectos que la autenticación mediante claves nunca protege: su token de administración y su archivo de copia de seguridad.

FAQ

¿Cómo desactivo el inicio de sesión con contraseña para SSH en Ubuntu 24.04?

Cree un archivo drop-in en /etc/ssh/sshd_config.d/00-hardening.conf. El prefijo 00 hace que se ordene antes que 50-cloud-init.conf, cuyo PasswordAuthentication yes tendría prioridad de otro modo, porque sshd conserva el primer valor que lee. Incluya PasswordAuthentication no y KbdInteractiveAuthentication no, ejecute sudo sshd -t para comprobar la configuración y después sudo systemctl reload ssh. Confirme que el inicio de sesión con clave funciona en una sesión nueva antes de depender de él. Editar un drop-in en lugar de sshd_config permite conservar el cambio durante las actualizaciones de paquetes y facilita revertirlo.

¿Debo desactivar el inicio de sesión de root mediante SSH?

Sí. Establezca PermitRootLogin no para que nadie pueda iniciar sesión directamente como root. Inicie sesión con su usuario normal y use sudo para las tareas administrativas. root existe en todos los sistemas Linux, por lo que dejarlo accesible proporciona a un atacante un nombre de usuario conocido como objetivo. Al desactivarlo, el atacante debe conocer el nombre de su cuenta y disponer de su clave.

¿Cambiar el puerto de SSH hace que mi servidor sea más seguro?

No de forma significativa. Cambiar el puerto 22 evita los escáneres simples que sólo comprueban el 22, lo que reduce el ruido en los registros. Sin embargo, un atacante real analiza todos los puertos y lo encuentra igualmente. La autenticación exclusiva con claves es lo que realmente evita las intrusiones. Si cambia el puerto, abra primero el nuevo puerto en el firewall y después ejecute sudo systemctl daemon-reload && sudo systemctl restart ssh.socket. En Ubuntu 24.04, el socket es el propietario del listener, y una recarga normal deja sshd en el puerto 22.

¿Necesito Fail2ban si uso claves SSH?

Es opcional, pero sigue siendo útil. Con la autenticación exclusiva con claves, los intentos de adivinar contraseñas no pueden tener éxito, por lo que Fail2ban no es lo que mantiene fuera a los atacantes. Limita la tasa de fallos repetidos desde una dirección, lo que reduce el ruido de los escáneres en los registros y expulsa pronto a los atacantes reincidentes. Un ataque lento y distribuido puede mantenerse por debajo de su umbral de bloqueo. Ejecútelo junto con la autenticación mediante claves y, preferiblemente, mantenga SSH detrás de una VPN.

¿Cómo recupero el acceso si me bloqueo fuera de SSH?

Use la consola web de su proveedor. Esta accede al servidor mediante una conexión serie o VNC que no pasa por SSH. Desde allí puede iniciar sesión, corregir el archivo drop-in de sshd y recargar el servicio. Por eso debe probar una configuración nueva de SSH en un segundo terminal antes de cerrar la primera sesión. También por eso la autenticación mediante claves ya debe funcionar antes de desactivar las contraseñas.