SSH seguro: la configuración que todo sysadmin debe aplicar

La configuración por defecto de SSH es funcional pero no es segura. Lo aprendí de la forma más didáctica posible: montando mi primer servidor y descubriendo al día siguiente que había tenido cientos de intentos de acceso de IPs desconocidas. Nadie entró, pero podría haber sido diferente con una contraseña más débil.

Desde entonces aplico esta configuración en cada servidor que monto, sea para proyectos del grado o para mis propios experimentos en casa. Son cambios que se hacen en 30 minutos y que reducen drásticamente la superficie de ataque.

Lo que vas a leer aquí no es teoría de manual sino lo que yo mismo tengo configurado en mis servidores.

SSH es la puerta de entrada a cualquier servidor Linux. Y como toda puerta, si la dejas con la configuración por defecto estás dejando la llave debajo del felpudo. En este artículo te explico las medidas concretas que debes aplicar para que tu servidor sea significativamente más difícil de comprometer.

Por qué la configuración por defecto no es suficiente

Cuando instalas un servidor Linux y activas SSH, por defecto permite el login con contraseña, permite intentos ilimitados de autenticación, escucha en el puerto 22 que es el primero que escanean los bots, y en muchos sistemas permite el login directo como root.

Esta combinación hace que cualquier servidor expuesto a internet empiece a recibir ataques de fuerza bruta en cuestión de minutos. No es exageración, puedes comprobarlo tú mismo mirando los logs de autenticación de un servidor recién instalado.

El archivo de configuración de SSH

Toda la configuración de SSH se gestiona desde el archivo sshd_config, que normalmente está en /etc/ssh/sshd_config. Antes de modificarlo haz siempre una copia de seguridad. Cualquier cambio requiere reiniciar el servicio SSH con systemctl restart sshd para que tenga efecto.

Una advertencia importante: nunca cierres tu sesión SSH activa antes de verificar que puedes abrir una nueva conexión con la nueva configuración. Si cometes un error y cierras la sesión, puedes quedarte sin acceso al servidor.

Medida 1: Deshabilitar el login de root

El usuario root tiene acceso total al sistema, por eso es el objetivo favorito de los ataques de fuerza bruta. Deshabilitar su acceso por SSH es la primera medida que debes aplicar.

En el archivo sshd_config busca la directiva PermitRootLogin y cámbiala a no. A partir de ese momento nadie podrá autenticarse directamente como root por SSH, tendrá que usar un usuario normal y luego escalar privilegios con sudo.

Antes de aplicar esto asegúrate de que tienes otro usuario con privilegios de sudo configurado y que puedes acceder con él.

Medida 2: Usar autenticación por clave pública

Las contraseñas pueden ser adivinadas por fuerza bruta. Las claves SSH no. Una clave SSH es un par de archivos criptográficos: la clave privada que guardas en tu máquina local y nunca compartes, y la clave pública que copias al servidor. Solo quien tenga la clave privada correspondiente puede autenticarse.

Para generar un par de claves usa el comando ssh-keygen en tu máquina local. El algoritmo recomendado actualmente es Ed25519, que es más seguro y genera claves más cortas que RSA. Puedes añadir una passphrase a la clave privada para añadir una capa extra de seguridad: aunque alguien robe el archivo de tu clave privada, no podrá usarla sin conocer la passphrase.

Una vez generadas las claves, copia la clave pública al servidor con ssh-copy-id. Este comando añade tu clave pública al archivo authorized_keys del usuario en el servidor.

Verifica que puedes conectarte con la clave antes de continuar con el siguiente paso.

Medida 3: Deshabilitar la autenticación por contraseña

Una vez que tienes la autenticación por clave funcionando, deshabilita completamente el acceso por contraseña. Esto hace que los ataques de fuerza bruta sean inútiles porque aunque adivinen la contraseña, el servidor no la aceptará.

En sshd_config cambia PasswordAuthentication a no y ChallengeResponseAuthentication también a no. Reinicia el servicio y verifica que puedes seguir conectándote con tu clave.

Medida 4: Cambiar el puerto por defecto

El puerto 22 es el primero que escanean los bots automatizados. Cambiarlo a un puerto alto como 2222 o cualquier número entre 1024 y 65535 no es una medida de seguridad real por sí sola, pero reduce drásticamente el ruido en los logs porque la mayoría de bots solo escanean el puerto 22.

En sshd_config cambia la directiva Port al número que elijas. Recuerda que si tienes un firewall activo también tendrás que abrir el nuevo puerto. Si usas ufw, añade el nuevo puerto con ufw allow seguido del número de puerto.

Medida 5: Limitar los usuarios que pueden conectarse

Si solo necesitas que uno o dos usuarios específicos accedan por SSH, puedes limitarlo con la directiva AllowUsers en sshd_config. Añade esta línea seguida de los nombres de usuario separados por espacios. Cualquier usuario que no esté en esa lista no podrá conectarse por SSH aunque tenga credenciales válidas.

Medida 6: Reducir los intentos de autenticación

Por defecto SSH permite varios intentos de autenticación por conexión. Reducir esto limita la eficacia de ciertos tipos de ataques. La directiva MaxAuthTries controla esto. Un valor de 3 es razonable para la mayoría de casos.

También puedes reducir el tiempo que SSH espera a que el usuario se autentique con la directiva LoginGraceTime. El valor por defecto es 120 segundos, con 30 es más que suficiente para un uso normal.

Medida 7: Deshabilitar características que no usas

Si no necesitas el reenvío X11 (para aplicaciones gráficas remotas), desactívalo con X11Forwarding no. Si no usas túneles SSH, desactiva AllowTcpForwarding. Cuantas menos características activas tenga SSH, menor es la superficie de ataque.

Verificar la configuración antes de reiniciar

SSH tiene un comando para verificar que la configuración es sintácticamente correcta sin aplicarla: sshd -t. Ejecútalo siempre antes de reiniciar el servicio. Si hay algún error en el archivo de configuración te lo indicará y podrás corregirlo antes de quedarte sin acceso.

La configuración completa

Resumiendo, las directivas más importantes que deberías tener en tu sshd_config son PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes, MaxAuthTries 3, LoginGraceTime 30, X11Forwarding no, y Port con el número que hayas elegido.

Con estas medidas aplicadas habrás eliminado los vectores de ataque más comunes contra SSH y tu servidor será significativamente más resistente.

Conclusión

La seguridad de SSH es una de esas cosas que solo te preocupa cuando ya has tenido un problema. No esperes a tener uno. Estas medidas se aplican en menos de 30 minutos y la diferencia en los logs de autenticación es inmediata: de cientos de intentos fallidos al día a prácticamente ninguno.

Combina esto con Fail2Ban que vimos en el artículo anterior y tendrás una defensa muy sólida para tu servidor.

¿Tienes alguna medida adicional que apliques en tus servidores? Compártela en los comentarios.