SSH es una de las piezas más críticas en cualquier servidor Linux. Es la puerta de entrada para la administración remota y, por tanto, uno de los primeros objetivos en auditorías de seguridad o escaneos de vulnerabilidades con herramientas como Nessus u OpenVAS.
Uno de los hallazgos más habituales en estos análisis es el temido “SSH Weak KEX”, que indica que el servidor aún permite algoritmos de intercambio de claves (Key Exchange, KEX) considerados débiles u obsoletos. Aunque el sistema funcione “correctamente”, mantener estos algoritmos activos supone un riesgo innecesario.
En esta entrada veremos, paso a paso, cómo endurecer (hardening) la configuración de SSH en Rocky Linux 9, deshabilitando KEX inseguros y asegurándonos de que el servidor solo acepte algoritmos modernos y robustos, sin comprometer la compatibilidad con clientes actuales.
Tabla de contenidos
¿Por qué es importante el intercambio de claves (KEX)?
Antes de entrar en comandos, merece la pena detenerse brevemente en la parte conceptual.
El Key Exchange es el mecanismo que permite a cliente y servidor SSH acordar una clave criptográfica segura al inicio de la conexión. Si este proceso utiliza algoritmos antiguos (por ejemplo, algunos basados en SHA-1), toda la sesión se debilita, aunque el resto de la configuración sea correcta.
Por eso, eliminar KEX obsoletos no es solo “cumplir una auditoría”: es cerrar una puerta real a posibles ataques criptográficos.
Crear un archivo de configuración de hardening
En Rocky Linux 9 (y en el resto de distribuciones basadas en Red Hat Enterprise Linux, así como en sistemas modernos con OpenSSH), el archivo principal de configuración incluye directivas adicionales desde un directorio específico:
Include /etc/ssh/sshd_config.d/*.conf
Esto permite una aproximación mucho más limpia y mantenible: en lugar de modificar directamente sshd_config, podemos crear archivos específicos para cada objetivo.
Creamos nuestro archivo de hardening:
sudo vi /etc/ssh/sshd_config.d/hardening.conf
Y añadimos el siguiente contenido:
# Disable weak key exchange algorithms KexAlgorithms curve25519-sha256,[email protected],diffie-hellman-group-exchange-sha256
Con esta configuración indicamos explícitamente que solo se permiten algoritmos de intercambio de claves seguros y modernos, dejando fuera opciones débiles como diffie-hellman-group1-sha1, que suelen ser las responsables de los avisos en auditorías.
Verificar la sintaxis antes de aplicar los cambios
Hay un paso que nunca debería omitirse cuando se trabaja con SSH: validar la configuración antes de reiniciar el servicio.
sudo sshd -t
- Si el comando no devuelve ningún mensaje, la configuración es válida.
- Si aparece algún error, es fundamental corregirlo antes de continuar.
Este pequeño gesto puede ahorrarte un bloqueo remoto del servidor.
Reiniciar el servicio SSH
Una vez validada la configuración, podemos aplicar los cambios:
sudo systemctl restart sshd
⚠️ Importante: no cierres tu sesión SSH actual hasta confirmar que puedes reconectarte correctamente. Una buena práctica consiste en abrir una segunda sesión de prueba antes de dar por finalizado el proceso.
Comprobar los algoritmos KEX activos
Para verificar que SSH está utilizando exactamente los algoritmos que hemos definido:
sshd -T | grep kex
La salida debería ser similar a:
kexalgorithms curve25519-sha256,[email protected],diffie-hellman-group-exchange-sha256
Esto confirma dos aspectos clave:
- Los algoritmos débiles han sido eliminados.
- El servidor sigue siendo compatible con clientes SSH modernos.
Prueba adicional (opcional, pero muy recomendable)
Si quieres ir un paso más allá, puedes comprobar activamente que un KEX débil ya no es aceptado. Desde otra máquina, intenta forzar un algoritmo antiguo:
ssh -oKexAlgorithms=diffie-hellman-group1-sha1 usuario@IP_DEL_SERVIDOR
El resultado esperado es:
no matching key exchange method found
Este mensaje es una buena señal: significa que el servidor rechaza activamente conexiones inseguras.
Conclusiones
Con este sencillo ajuste de hardening:
- SSH utiliza exclusivamente algoritmos de intercambio de claves seguros.
- Se eliminan hallazgos habituales como SSH Weak KEX en auditorías.
- Se mantiene la compatibilidad con clientes actuales.
- La configuración resulta limpia, mantenible y apta para entornos de producción.
Pequeños cambios como este marcan una gran diferencia en la superficie de ataque de un servidor. Y lo mejor es que, una vez aplicado, se convierte en un problema del que puedes olvidarte durante mucho tiempo.
Nota: La imagen de este artículo fue generada utilizando un modelo de inteligencia artificial.
Deja una respuesta