como asegurar ssh en un vps

Por qué SSH es lo primero que se debe proteger

SSH es el método para controlar su servidor, lo que lo convierte en la cerradura que todo atacante intenta vulnerar primero. En cuanto un VPS está en línea, los escáneres comienzan a probar nombres de usuario y contraseñas en el puerto 22. Puede observar este proceso en sus logs en cuestión de minutos. Proteger SSH consiste en eliminar los elementos que pueden adivinar: desactive completamente el inicio de sesión por contraseña, desactive el inicio de sesión como root y permita únicamente el uso de claves criptográficas. Una vez hecho esto, los intentos de adivinación fallarán, ya que no habrá contraseñas que encontrar.

Esto asume que ya tiene SSH funcionando. Si puede iniciar sesión, puede protegerlo. Realice los pasos en orden y mantenga su sesión actual abierta hasta que una nueva sesión funcione; así evitará quedar bloqueado por un error.

Paso 1: Verifique primero que la autenticación por clave funcione

La autenticación por clave reemplaza la contraseña por un par de claves: una clave privada que permanece en su equipo y una clave pública que se instala en el servidor. El servidor verifica que usted posee la clave privada sin que esta salga de su máquina. Antes de deshabilitar las contraseñas, confirme que las claves funcionan para evitar perder el acceso al sistema.

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

ssh-keygen -t ed25519

Copie la mitad pública al servidor:

ssh-copy-id user@your-server

Luego, abra una nueva sesión SSH. Si el acceso se realiza sin solicitar una contraseña, la clave funciona y puede desactivar las contraseñas de forma segura. Si no tiene experiencia con claves o utiliza más de un equipo, conceptos básicos de gestión de claves SSH explica el modelo completo: una clave por dispositivo, los permisos que requiere sshd y cómo revocar una clave si se pierde un portátil.

Paso 2: Reforzar sshd con un archivo drop-in

No edite /etc/ssh/sshd_config directamente. Ubuntu 24.04 lee archivos drop-in desde /etc/ssh/sshd_config.d/. Un archivo pequeño en esa ubicación es más limpio, persiste tras las actualizaciones de paquetes y es fácil de eliminar si ocurre un error. El nombre es importante: sshd conserva el primer valor que lee para cada configuración, y las imágenes de Ubuntu cloud incluyen 50-cloud-init.conf con PasswordAuthentication yes en este directorio. Nombre su archivo 00- para que se ordene antes que el original y tenga prioridad; un archivo 99- pierde la prioridad sin avisar. Cree uno:

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

Coloque esto en:

# 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: al desactivar las contraseñas, un ataque de fuerza bruta no tiene nada 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 poseer su clave, en lugar de simplemente atacar la cuenta root que existe en todos los sistemas.

Paso 3: Probar la configuración y recargar

Verifique la configuración para detectar errores antes de aplicarla; esto evita que un error tipográfico interrumpa el servicio:

sudo sshd -t

Si no se muestra ningún mensaje, la configuración es válida. Recargue SSH:

sudo systemctl reload ssh

Luego, verifique los parámetros que sshd está utilizando realmente para detectar posibles conflictos con otros archivos:

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

Ambos deben mostrar no. Ahora, sin cerrar su sesión actual, abra una sesión nueva desde otra terminal. Si inicia sesión con su clave, el proceso ha finalizado. Si ocurre un error, su primera sesión sigue abierta para corregirlo. Esta redundancia es su red de seguridad; no la omita.

Paso 4: El puerto no estándar opcional

Cambiar SSH del puerto 22 a uno como 2222 no aumenta la seguridad real, ya que un atacante decidido escanea todos los puertos. Lo que logra es reducir el ruido en los logs, puesto que la mayoría de los escáneres automatizados solo prueban el puerto 22. Si desea realizar el cambio, añada Port 2222 a su archivo de configuración, permita primero el nuevo puerto en el firewall, luego ejecute sudo systemctl daemon-reload && sudo systemctl restart ssh.socket y conéctese con ssh -p 2222. En Ubuntu 24.04, ssh.socket gestiona el puerto de escucha, por lo que un reload ssh simple mantiene sshd en el 22; reiniciar el socket es lo que aplica el nuevo puerto. Considere esto como una medida de orden, no de protección.

Paso 5: Añadir capas de defensa adicionales

Las llaves SSH protegidas son la base, y se pueden añadir dos capas adicionales sobre ellas.

Fail2ban monitoriza los logs y bloquea las direcciones con intentos fallidos constantes. Esto reduce el ruido de los scanners y los expulsa rápidamente. Funciona de forma ideal con la autenticación basada solo en llaves: consulte Fail2ban en Ubuntu para detener ataques SSH.

Una opción más segura es mantener SSH fuera de la internet pública. Si usted configura SSH tras una VPN WireGuard y limita el puerto 22 al túnel, nadie fuera de la VPN podrá alcanzarlo. Esto hace que los ataques de fuerza bruta dejen de ser posibles en lugar de solo difíciles. Todo esto requiere un firewall con política de denegación por defecto, como UFW configurado en el VPS.

SSH es solo un paso de una lista más extensa: los primeros 10 minutos en un nuevo VPS establece el orden de los pasos, y actualizaciones de seguridad automáticas en Ubuntu mantiene el sistema parcheado posteriormente.

FAQ

¿Cómo desactivo el inicio de sesión por 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 ganaría de otro modo, ya que sshd mantiene el primer valor que lee) que contenga PasswordAuthentication no y KbdInteractiveAuthentication no, ejecute sudo sshd -t para verificarlo y luego sudo systemctl reload ssh. Confirme que el inicio de sesión por clave funciona en una nueva sesión antes de confiar en ello. Editar un drop-in en lugar de sshd_config sobrevive a las actualizaciones de paquetes y es fácil de revertir.

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

Sí. Configure PermitRootLogin no para que nadie pueda iniciar sesión directamente como root. Inicie sesión con su usuario normal y use sudo para tareas de administración. Root existe en cada sistema Linux, por lo que dejarlo accesible entrega a un atacante un nombre de usuario conocido para atacar. Desactivarlo significa que deben conocer su nombre de cuenta y poseer su clave.

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

No significativamente. Salir del puerto 22 le oculta de los escáneres básicos que solo prueban el puerto 22, lo que reduce el ruido en los logs, pero un atacante real escanea todos los puertos y lo encontrará de todos modos. La autenticación solo por clave es lo que realmente detiene las intrusiones. Si cambia el puerto, abra primero el nuevo puerto en el firewall y luego ejecute sudo systemctl daemon-reload && sudo systemctl restart ssh.socket; en Ubuntu 24.04 el socket gestiona el listener, y un reload simple dejará a sshd en el puerto 22.

¿Necesito Fail2ban si uso claves SSH?

Es opcional pero sigue siendo útil. Con autenticación solo por clave, el ataque de fuerza bruta por contraseña no puede tener éxito, por lo que Fail2ban no es lo que mantiene fuera a los atacantes. Este limita la frecuencia de fallos repetidos desde una misma dirección, lo que reduce el ruido de los escáneres en sus logs y expulsa a los infractores recurrentes rápidamente; un ataque lento y distribuido se mantiene bajo su umbral de baneo de todos modos. Ejecútelo junto con la autenticación por clave y, de forma ideal, mantenga SSH detrás de una VPN.

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

Use la consola web de su proveedor, la cual accede al servidor mediante una conexión serial o VNC que no pasa por SSH. Desde allí puede iniciar sesión, corregir el archivo drop-in sshd y recargar el servicio. Esta es exactamente la razón por la que se debe probar una nueva configuración de SSH en una segunda terminal antes de cerrar la primera sesión, y por la que la autenticación por clave ya debe estar funcionando antes de desactivar las contraseñas.