Cuando migré 300 VMs VMware para una organización sanitaria pública con 2.000 endpoints, la primera línea de defensa fue blindar el acceso remoto. SSH (Secure Shell) es la espina dorsal de la administración remota, pero una configuración por defecto es una invitación abierta para los atacantes. He visto demasiadas infraestructuras expuestas a riesgos innecesarios por configuraciones SSH débiles. Un solo punto débil puede desencadenar un desastre operativo que ponga en riesgo la continuidad del negocio. Este artículo te guiará a través de diez ajustes esenciales para blindar tus servidores Linux, reduciendo la superficie de ataque de forma drástica y aumentando la resiliencia contra intentos de intrusión. Implementando estas prácticas, protegerás tus endpoints y cargas de trabajo de accesos no autorizados, garantizando un control proactivo sobre tu infraestructura conforme a estándares como NIS2 art.21.
Requisitos Previos y Entorno de Prueba para Hardening SSH
Para seguir esta guía necesitas un servidor Linux (Ubuntu Server 22.04 LTS o CentOS Stream 9) con acceso sudo. Ejecuta todos los comandos desde terminal. Antes de modificar la configuración SSH, crea una copia de seguridad del archivo sshd_config. Esto te permite restaurar la configuración previa si algo falla, evitando quedarte fuera del servidor. Nuestro foco principal, el hardening SSH en Linux, garantiza la máxima seguridad desde la base.
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bakAjustes de Red y Autenticación Básica
Cambiar el puerto SSH por defecto
El puerto 22 es el objetivo principal de ataques automatizados y escaneos. Cambiarlo a un valor no estándar no ofrece seguridad intrínseca, un atacante determinado siempre puede escanear todos los puertos, pero reduce el ruido de fondo y los intentos de fuerza bruta automatizados. Todavía no tengo una respuesta definitiva sobre si la seguridad por oscuridad es una estrategia a largo plazo, pero los logs más limpios son un beneficio tangible. Elige un puerto alto no utilizado por otros servicios. En /etc/ssh/sshd_config, busca la línea Port 22 y modifícala:
#Port 22
Port 2222Abre la nueva puerta en el firewall (sudo ufw allow 2222/tcp para UFW o sudo firewall-cmd --permanent --add-port=2222/tcp --zone=public && sudo firewall-cmd --reload para Firewalld).
Deshabilitar el login como root
Permitir el acceso directo como root vía SSH es una práctica riesgosa. Si un atacante adivina la contraseña de root, obtiene el control total del sistema. Es mucho más seguro acceder con un usuario estándar y elevar privilegios mediante sudo cuando sea necesario. Esto añade una capa adicional de protección y trazabilidad. En /etc/ssh/sshd_config, establece:
PermitRootLogin noUsar solo autenticación por clave pública
Las contraseñas son vulnerables a ataques de fuerza bruta y diccionario. La autenticación por clave pública, basada en pares criptográficos (una pública en el servidor, una privada en el cliente), es mucho más robusta y recomendada para entornos de producción. Requiere que protejas la clave privada en el cliente. En /etc/ssh/sshd_config, establece:
PasswordAuthentication no
PubkeyAuthentication yesAsegúrate de haber configurado el acceso por clave SSH antes de deshabilitar la contraseña, de lo contrario te quedarás fuera del servidor.
Limitar los usuarios con acceso SSH
No todos los usuarios del sistema necesitan acceso SSH. Limita el acceso solo a las cuentas estrictamente necesarias. Esto reduce la superficie de ataque y minimiza el riesgo de que cuentas comprometidas se utilicen para acceso remoto. En /etc/ssh/sshd_config, añade o modifica:
AllowUsers nombreusuarioPuedes especificar múltiples usuarios separados por espacios: AllowUsers usuario1 usuario2.
Endurecimiento de Sesiones y Protocolo
Habilitar el timeout de sesión inactiva
Las sesiones SSH abiertas e inactivas representan un riesgo. Si un administrador se aleja del terminal sin bloquearlo, un actor malicioso podría secuestrar la sesión activa. Configurar un timeout automático mitiga este riesgo. En /etc/ssh/sshd_config, añade:
ClientAliveInterval 300
ClientAliveCountMax 2ClientAliveInterval 300 indica que el servidor enviará un mensaje keep-alive al cliente cada 300 segundos (5 minutos). ClientAliveCountMax 2 significa que si el cliente no responde a 2 mensajes seguidos, la sesión se cierra. Una sesión inactiva se terminará tras 10 minutos (300s * 2).
Deshabilitar protocolos SSH obsoletos
Las versiones antiguas del protocolo SSH (especialmente SSHv1) contienen vulnerabilidades conocidas. Asegúrate de que tu servidor utilice solo SSHv2. Suele ser el valor por defecto en distribuciones modernas, pero conviene verificarlo explícitamente para cumplir con auditorías ISO 27001:2022. En /etc/ssh/sshd_config, establece:
Protocol 2Limitar los intentos de login (MaxAuthTries)
Para frenar los ataques de fuerza bruta, limita el número de intentos de autenticación permitidos por conexión. Al superar este límite, la conexión SSH se termina de inmediato. En /etc/ssh/sshd_config, añade o modifica:
MaxAuthTries 3Un valor demasiado bajo puede frustrar a los usuarios legítimos, mientras que uno demasiado alto hace ineficaz la protección. Tres intentos es un equilibrio razonable.
Usar AllowUsers y DenyUsers
Además de AllowUsers, puedes usar DenyUsers para especificar usuarios a los que se les deniega explícitamente el acceso SSH. AllowGroups y DenyGroups funcionan igual para grupos enteros. Es una buena práctica usar AllowUsers o AllowGroups para un control restrictivo mediante listas blancas, en lugar de listar lo que no debe entrar.
AllowUsers alice bob
DenyUsers guestHabilitar el log detallado (VERBOSE)
Para facilitar la resolución de problemas y el monitoreo de seguridad, habilita un nivel de registro más detallado para el servicio SSH. Esto proporciona más información sobre eventos de login, intentos fallidos y otras actividades, lo cual es esencial para un SIEM o un EDR como Wazuh para detectar anomalías antes de que se propaguen. En /etc/ssh/sshd_config, establece:
LogLevel VERBOSEVerificar la configuración y reiniciar
Antes de reiniciar el servicio SSH, verifica la sintaxis del archivo de configuración. Un error te puede bloquear fuera del servidor. El comando sshd -t ejecuta una prueba sintáctica sin aplicar los cambios.
sudo sshd -tSi no muestra ningún resultado, la sintaxis es correcta. Si hay errores, indicará el problema y la línea exacta del archivo. Tras verificar, reinicia el servicio. Mantén una sesión SSH abierta mientras pruebas la nueva configuración desde otra ventana. Si algo falla, puedes revertir con la sesión anterior.
sudo systemctl restart sshdConéctate desde un nuevo terminal usando el nuevo puerto y ajustes (ssh -p 2222 usuario@direccion_ip). Si la conexión tiene éxito, cierra la sesión antigua.
Errores Comunes y Resolución de Problemas
- Bloqueado fuera del servidor: El problema más común. Si pierdes acceso SSH, entra por consola directa (VMware vSphere Console, OCI Console, KVM) y restaura el archivo
/etc/ssh/sshd_config.bakque creaste al inicio. Reiniciasshdy vuelve a intentarlo. - Problemas de firewall: Si cambiaste el puerto SSH pero no lo abriste en el firewall, las conexiones se bloquearán. Verifica las reglas (
sudo ufw statusosudo firewall-cmd --list-all). - Permisos de claves SSH: Las claves privadas deben tener permisos
600(chmod 600 ~/.ssh/id_rsa) y el directorio.sshpermisos700(chmod 700 ~/.ssh). En el servidor, el archivo~/.ssh/authorized_keysdebe tener permisos600. sshd -treporta errores: Lee la salida del comando con atención. Indica la línea exacta del archivosshd_configdonde está el error de sintaxis.
Lee también: UFW Firewall Ubuntu: Configuración Completa Paso a Paso
Conclusiones con Puntos Clave Operativos
El hardening SSH en Linux no es una opción, es una necesidad operativa. Implementar estos diez ajustes esenciales te otorga un control estricto sobre el acceso a tus servidores, reduciendo el riesgo de compromisión de manera significativa. Deshabilitar el login de root, usar autenticación por clave pública y cambiar el puerto por defecto ofrecen un retorno de seguridad inmediato con un esfuerzo mínimo. Cada servidor Linux expuesto a internet debería tener estas configuraciones activas hoy, no mañana. Para profundizar en las opciones de configuración, consulta la página man de sshd_config.
Recuerda probar siempre los cambios en un entorno de staging antes de aplicarlos en producción y tener un plan de rollback documentado. La seguridad es un proceso continuo, y la actualización constante de las buenas prácticas es fundamental para mantener la integridad de tus infraestructuras según el marco NIST CSF 2.0.
