Endurecimiento de SSH en Linux: controles concretos antes del kernel

En la mayoría de servidores Linux empresariales, el vector de entrada más explotado no es un fallo del kernel ni un módulo cargado de más: es SSH. Cuentas con contraseña, root accesible directamente, claves sin passphrase y puertos de administración alcanzables desde redes no corporativas concentran buena parte del riesgo real. Este artículo no propone una secuencia general de priorización de controles de hardening Linux —ese ángulo ya está cubierto en el blog de Mister IT—, sino que se enfoca en un subconjunto técnico concreto: qué endurecer en el servicio SSH y en las cuentas que lo usan, con criterios verificables.

Por qué SSH merece un tratamiento propio

SSH es el único servicio que casi todo servidor Linux expone. A diferencia de un motor de base de datos o un servidor web, no se puede apagar si no se usa: es la vía de administración. Eso lo convierte en un objetivo permanente y en un punto donde un error de configuración tiene consecuencias directas sobre la operación.

Tres razones justifican tratarlo como bloque independiente dentro del hardening:

• Es alcanzable por defecto. Un servidor recién aprovisionado suele aceptar autenticación por contraseña y permitir root directo hasta que alguien lo cambia.
• Concentra credenciales. Claves privadas, agentes, known_hosts y configuraciones de ~/.ssh son activos que rara vez se inventarían.
• Su configuración es verificable. A diferencia de controles de kernel con efectos difusos, sshd_config y los permisos de ~/.ssh se pueden auditar de forma objetiva y automatizable.

Controles sobre sshd_config que conviene revisar primero

La configuración del demonio SSH es el punto de partida. Estos parámetros son los que aparecen con más frecuencia mal configurados en entornos productivos:

• PermitRootLogin: debe estar en no o, si se requiere por razones operativas justificadas, en prohibit-password con clave y origen restringido. yes con contraseña es el caso más grave.
• PasswordAuthentication: en servidores con acceso administrativo nominal, no. La autenticación por clave pública elimina el vector de fuerza bruta y de reutilización de credenciales.
• PermitEmptyPasswords: siempre no. Su presencia en yes suele indicar configuración heredada sin revisión.
• PubkeyAuthentication: yes, con algoritmos modernos. Conviene revisar PubkeyAcceptedAlgorithms para excluir ssh-rsa con SHA-1 cuando la flota lo permita.
• X11Forwarding: no salvo necesidad explícita. Reduce superficie y evita túneles no previstos.
• AllowTcpForwarding y PermitTunnel: no cuando no se usan. Limitan el uso del servidor como pivote.
• MaxAuthTries y LoginGraceTime: valores bajos (por ejemplo, 3 y 30s) reducen la ventana de intentos automatizados.
• ClientAliveInterval y ClientAliveCountMax: cierran sesiones inactivas, útil en consolas olvidadas.

Cualquier cambio en sshd_config debe validarse con sshd -t antes de reiniciar el servicio. Un error de sintaxis que impida arrancar sshd en un servidor remoto puede dejar el activo inaccesible hasta intervención por consola.

Restricción de origen y separación de planos

Endurecer la autenticación sin restringir el origen deja la mitad del trabajo hecho. Un servidor con clave pública obligatoria pero alcanzable desde cualquier red sigue expuesto a intentos, escaneos y explotación de vulnerabilidades del propio demonio.

Controles concretos:

• Filtrado por origen en el firewall del host (nftables, firewalld) o en la ACL de red, limitando el puerto 22 a rangos de administración conocidos.
• Match Address en sshd_config para aplicar políticas distintas según el origen: por ejemplo, exigir MFA o clave específica desde redes menos confiables.
• AllowUsers / AllowGroups para limitar qué cuentas pueden autenticarse, en lugar de confiar en que nadie más lo intentará.
• Bastión o jump host cuando el número de servidores lo justifica. Centraliza autenticación, registro y control de acceso, y reduce los puntos con SSH expuesto.
• Puerto no estándar: no es un control de seguridad real, pero reduce ruido de escaneo automatizado. No debe presentarse como medida de protección.

La separación de planos —administración por una vía distinta al tráfico de aplicación— es especialmente relevante en servidores con exposición a Internet. Si el mismo puerto que sirve tráfico sirve administración, cualquier compromiso del servicio de aplicación acerca al atacante al plano de control.

Cuentas, claves y permisos: el control que suele quedar pendiente

La configuración del demonio es solo una parte. El estado de las cuentas y las claves determina qué puede hacer quien logra autenticarse.

Puntos a revisar:

• Cuentas con shell válido. En /etc/passwd, cualquier cuenta que no requiera login interactivo debería tener /sbin/nologin o /bin/false. Cuentas de servicio con /bin/bash son un hallazgo recurrente.
• Claves autorizadas. ~/.ssh/authorized_keys acumula claves a lo largo del tiempo. Conviene inventariarlas, asociarlas a una persona o sistema, y eliminar las que no tengan dueño identificable.
• Claves sin passphrase. En cuentas humanas, una clave sin passphrase equivale a una contraseña almacenada en disco. En cuentas de automatización puede ser aceptable si el acceso está restringido por origen y comando forzado.
• Permisos. ~/.ssh en 700, authorized_keys en 600, propiedad del usuario correcto. Permisos laxos hacen que sshd rechace la clave o, peor, que otro usuario local pueda modificarla.
• sudo y escalada. El acceso administrativo debería pasar por sudo con registro, no por sesión directa de root. Revisar /etc/sudoers y /etc/sudoers.d/ para detectar reglas NOPASSWD amplias o ALL=(ALL) ALL sin justificación.
• Rotación y revocación. Definir cómo se retira el acceso cuando alguien deja la organización o cambia de rol. Sin este procedimiento, el inventario de claves se degrada rápido.

Verificación y registro: cómo saber que el control sigue en pie

Un control aplicado una vez no permanece aplicado. Los cambios de configuración, las reinstalaciones y las excepciones operativas reintroducen configuraciones inseguras.

Mecanismos razonables:

• Verificación periódica automatizada de los parámetros críticos de sshd_config y de los permisos de ~/.ssh, con alerta ante desviación.
• Registro de autenticaciones (/var/log/auth.log, journald) enviado a un colector central fuera del propio servidor. Sin esto, un compromiso puede borrar la evidencia local.
• Sincronización horaria (chrony o NTP) correcta: sin ella, la correlación de eventos entre servidores es inviable.
• Auditoría de comandos privilegiados vía sudo con log_output o reglas de auditd sobre execve, según el nivel de detalle requerido.
• Revisión de intentos fallidos como señal operativa: un aumento sostenido de intentos contra un servidor puede indicar reconocimiento previo.

En el contexto chileno, esta capa de trazabilidad es la que sostiene la preparación frente a marcos como la Ley 21.719: evidencia de accesos, cambios y responsables. Conviene hablar de preparación y de evidencia disponible, no de cumplimiento garantizado.

Cómo encajar esto en una operación existente

Este bloque de controles no reemplaza una estrategia de hardening más amplia, pero sí se puede abordar como unidad acotada, con alcance y verificación claros. Un orden operativo razonable:

1. Inventariar servidores con SSH expuesto y clasificar por criticidad y origen de acceso.
2. Aplicar los controles de sshd_config en preproducción, validar con sshd -t y desplegar por ventana.
3. Restringir origen en firewall o ACL, empezando por los activos de mayor exposición.
4. Limpiar cuentas y claves con un inventario explícito de responsables.
5. Consolidar registro centralizado y verificación periódica de la configuración.

Si tu operación necesita ordenar estos controles sobre inventario real y no sobre plantillas genéricas, en Hardening & Seguridad trabajamos el endurecimiento de SSH y de los planos de administración con criterio de exposición y criticidad.