Cómo endurecer la configuración del servidor SSH
Última actualización:
El archivo sshd_config es toda la postura de seguridad de tu servidor SSH en un solo archivo de texto, y en la mayoría de los sistemas llega en un estado optimizado para la compatibilidad, no para la seguridad. El inicio con contraseña viene activado por defecto, root puede entrar siempre que use una clave, las sesiones inactivas no caducan nunca y los algoritmos que ofrece tu servidor son los que decidió la versión de OpenSSH instalada hace años. Endurecerlo no consiste en copiar una lista de 2021: los algoritmos se retiran, los valores por defecto cambian y una configuración que era ejemplar hace cinco años puede ser débil hoy. Este artículo explica qué hace realmente cada cambio, por qué importa el orden de tus decisiones y cómo probar una configuración nueva sin quedarte fuera. Puedes auditar tu propio archivo línea por línea en el auditor de configuración del servidor SSH, que lo compara con una base de referencia fechada el 2026-11-13, todo en tu navegador.
Los valores por defecto son un punto de partida, no una postura de seguridad
OpenSSH llega con valores por defecto elegidos para que una instalación nueva funcione para la mayor cantidad de gente posible, y esa es exactamente la razón por la que no son una postura de seguridad. Los valores actuales, según documenta la página del manual de sshd_config, incluyen PasswordAuthentication yes, PermitRootLogin prohibit-password, MaxAuthTries 6, LoginGraceTime 120 segundos y ClientAliveInterval 0, lo que significa que las sesiones inactivas nunca se terminan. Ninguno de ellos es un error: cada uno es una decisión deliberada de compatibilidad, y cada uno es un hallazgo en una auditoría de endurecimiento.
La consecuencia práctica es que un servidor que nadie ha endurecido sigue siendo alcanzable por adivinación de contraseñas, sigue aceptando inicios de root con una clave robada y sigue dejando sesiones abandonadas abiertas indefinidamente. Los valores por defecto también cambian con el tiempo —lo que trae OpenSSH 10.6 no es lo que traía OpenSSH 7—, así que «yo nunca cambié nada» no es una afirmación neutra. Significa que tu postura de seguridad es la que decidió la versión que te tocó instalar, y la única forma de saberlo es leer el archivo. Ese es el primer trabajo de una auditoría: hacer visibles los valores por defecto invisibles, porque una directiva que no aparece en el archivo sigue en vigor.
Apagar las contraseñas vale más que cambiar el puerto, siempre
El cambio más eficaz en sshd_config es PasswordAuthentication no combinado con PubkeyAuthentication yes: a partir de ese momento, ninguna contraseña —adivinada, filtrada o robada por phishing— puede abrir una sesión, porque el demonio ya no acepta ese tipo de prueba. La autenticación por clave cambia el ataque de «adivinar un secreto que eligió un humano» a «robar un archivo de clave privada que nunca cruza la red», y por eso todas las bases de endurecimiento, incluida la de Mozilla, empiezan aquí. Si te quedas con una sola cosa de este artículo, que sea esta: genera un par de claves (consulta el generador de claves SSH y el artículo las claves SSH explicadas), instala la clave pública, verifica que puedes entrar con ella y solo entonces apaga las contraseñas.
Cambiar el puerto del 22 a otro más oscuro, en cambio, no es endurecer: es oscuridad. Reduce el ruido en tus registros, porque la mayoría de los escáneres de internet solo llaman al puerto 22, pero no detiene a ningún atacante que se moleste en escanear: un escaneo de puertos encuentra el demonio en segundos, y el demonio que hay detrás es exactamente tan fuerte como su configuración. Por eso el auditor trata un puerto distinto del 22 solo como información, nunca como una mejora puntuada. Hay una trampa que conviene conocer antes de accionar el interruptor: en sistemas que usan PAM, PasswordAuthentication no por sí solo no basta —la autenticación por teclado interactivo puede seguir dejando que PAM acepte una contraseña, así que la pila PAM de /etc/pam.d/sshd también debe rechazar las contraseñas. Las directrices de Mozilla lo dicen explícitamente, y es la mitad del cambio que más se olvida.
Inicio de root: qué permite realmente prohibit-password
PermitRootLogin tiene cuatro valores, y la diferencia entre ellos es la diferencia entre tener un rastro de auditoría o no tenerlo. El valor por defecto, prohibit-password, permite que root inicie sesión, solo que no con contraseña. Una clave de root robada entra igualmente sin obstáculos, y una vez que la sesión es root, nada en los registros distingue a un administrador de otro. El perfil Modern de Mozilla lo fija en No, y esa es la respuesta endurecida: root no debería ser nunca una cuenta de inicio de sesión. Entra como un usuario con nombre y usa sudo; entonces cada acción privilegiada es atribuible a una persona.
Los valores intermedios existen por una razón, y vale la pena conocerlos en lugar de temerlos. forced-commands-only permite el inicio de root solo cuando la clave ofrecida está restringida a un único comando en authorized_keys —el patrón que usan los scripts de copia de seguridad y monitorización— y es una elección legítima y deliberada para la automatización. Lo que no es legítimo es yes, que permite el inicio de root con contraseña y es un error en cualquier auditoría. La regla práctica: si un humano entra como root, la configuración está mal; si lo hace un script, restringe la clave a un comando y dilo en un comentario, porque la próxima persona que lea el archivo lo «arreglará» si no.
La retirada de algoritmos es un objetivo en movimiento
Los algoritmos de tu configuración tienen fecha de caducidad, y es más corta de lo que crees. OpenSSH 10.0, publicado el 2025-04-09, eliminó por completo la compatibilidad con DSA (ssh-dss), retiró el Diffie-Hellman de campo finito del intercambio de claves por defecto del servidor e hizo de mlkem768x25519-sha256 —un híbrido poscuántico— el acuerdo de claves por defecto. Una configuración copiada de un blog de 2021 puede seguir listando diffie-hellman-group1-sha1, 3des-cbc, arcfour o hmac-md5, todos ellos errores en una auditoría moderna, y algunos de los cuales el demonio instalado ya ni siquiera admite. La configuración no cambió; el mundo sí.
Por eso una base de endurecimiento debe llevar fecha, y por eso volver a comprobar es parte del trabajo, no un pensamiento posterior. El perfil Modern de Mozilla —intercambio de claves curve25519, cifrados chacha20-poly1305 y AES-GCM, MAC SHA-2 de cifrar-y-luego-autenticar— es la referencia, pero es anterior a los intercambios de claves poscuánticos que OpenSSH 10.0 hizo por defecto, así que una auditoría de 2026 acepta mlkem768x25519-sha256 y sntrup761x25519-sha512 junto a ellos. El hábito que te mantiene al día es barato: una o dos veces al año, ejecuta ssh -Q kex, ssh -Q cipher y ssh -Q mac en el servidor para ver lo que realmente ofrece la versión instalada, compáralo con las directrices actuales de Mozilla y vuelve a pasar el auditor sobre el mismo archivo. Una puntuación limpia de 2021 es un documento histórico, no uno actual.
Bloques Match e Include: las dos formas en que una auditoría limpia miente
Un archivo de configuración no es una lista plana de ajustes: es un programa con ramas condicionales, y dos funciones pueden hacer que un archivo que se lee como endurecido se comporte como si no lo estuviera. La primera es el bloque Match: las directivas dentro de Match User, Match Group o Match Address solo se aplican cuando se cumplen los criterios, y la página del manual es explícita: si una palabra clave aparece en varios bloques Match satisfechos, solo se aplica la primera instancia. Un PasswordAuthentication no global seguido de un bloque Match que vuelve a habilitar discretamente las contraseñas para un grupo es una configuración real, y es justo el tipo de cosa que una lectura línea por línea pasa por alto. Los hallazgos de dentro de un bloque Match son condicionales, nunca globales, y cualquier auditoría honesta los delimita así.
La segunda es Include. Las distribuciones modernas dividen sshd_config en varios archivos —/etc/ssh/sshd_config.d/*.conf es el patrón habitual— y una directiva Include incorpora esos archivos, en orden léxico, en el punto en el que aparece. Como gana el primer valor obtenido, una directiva fijada en un archivo incluido eclipsa la misma directiva más adelante en el archivo principal: la línea que lees no es la línea que manda. Un auditor que corre en el navegador no puede seguir los Includes —los archivos no están en tu máquina—, así que los marca como «no seguidos» y lista la ruta. Cuando audites, audita todo el directorio, no un solo archivo, y recuerda que una directiva duplicada no es un error tipográfico que ignorar: la primera gana y la segunda es texto muerto que confundirá a la próxima persona que edite el archivo.
El despliegue seguro: prueba antes de cerrar la puerta
Cada cambio en sshd_config conlleva el mismo riesgo: un error tipográfico puede impedir que el demonio se reinicie, y un ajuste correcto pero equivocado puede impedirte entrar a ti. El despliegue que evita ambas cosas es corto y no negociable. Primero, comprueba la sintaxis con sshd -t antes de tocar el servicio en ejecución: analiza el archivo e informa de errores sin arrancar nada. Después reinicia o recarga el demonio, y solo entonces prueba. Nunca edites la configuración y cierres tu única sesión en el mismo gesto.
La prueba en sí es la disciplina: mantén tu sesión actual abierta, abre una segunda sesión e inicia sesión de nuevo con las reglas nuevas en vigor. Si el segundo inicio funciona, el cambio es seguro y la primera sesión puede cerrarse; si no, la sesión abierta es tu camino de vuelta, y puedes revertir el archivo y recargar. Por eso también los cambios deben hacerse de uno en uno en un servidor al que no puedes llegar físicamente: un archivo de claves roto y un método de contraseña desactivado en la misma edición no dejan ninguna salida. El auditor puede producir una versión endurecida de tu archivo como punto de partida, pero es un borrador para revisar, bloque Match a bloque Match, y probar con sshd -t, nunca un archivo para soltar sin revisar.