SSH poscuántico: mlkem768x25519-sha256 en OpenSSH

OpenSSH ya incorpora hoy el acuerdo de claves poscuántico, sin bibliotecas adicionales y sin parches. El método híbrido mlkem768x25519-sha256 se añadió en OpenSSH 9.9 (19 de septiembre de 2024) y pasó a ser el acuerdo de claves por defecto en OpenSSH 10.0 (9 de abril de 2025). Esta guía explica cómo saber qué método ha negociado realmente una sesión, cómo dar preferencia al método híbrido en las versiones que lo admiten sin usarlo por defecto, qué significa el aviso de OpenSSH 10.1 sobre los acuerdos de claves no poscuánticos y por qué las claves de host SSH siguen siendo clásicas.

Qué hace realmente mlkem768x25519-sha256

El nombre describe la construcción: ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, un KEM o mecanismo de encapsulamiento de claves) con el conjunto de parámetros 768, X25519 (Diffie-Hellman sobre curva elíptica con Curve25519) y SHA-256 como función hash. El NIST publicó ML-KEM como FIPS 203 el 13 de agosto de 2024 (FIPS 203), y la página de referencia de ML-KEM recoge sus conjuntos de parámetros y su estado.

El método es híbrido: la clave de sesión se deriva tanto del secreto compartido de ML-KEM como del secreto compartido de X25519. Un cliente y un servidor que lo negocian quedan protegidos mientras al menos uno de los dos componentes resista. Es la opción prudente mientras las implementaciones poscuánticas son todavía jóvenes, y es lo que señalan las guías europeas: un acuerdo de claves híbrido en lugar de un intercambio puramente poscuántico.

El acuerdo de claves es la primera prioridad en SSH por la misma razón que en TLS. Un atacante que graba hoy una sesión cifrada puede almacenarla y atacarla más adelante. Es el escenario «recolectar ahora, descifrar después» (HNDL, harvest now, decrypt later), descrito en nuestro artículo sobre recolectar ahora, descifrar después. Si el intercambio fue puramente clásico, un ordenador cuántico suficientemente potente permitiría descifrar retroactivamente el tráfico grabado. La autenticación es distinta: un atacante capaz de falsificar una firma de host tiene que usarla durante una conexión en curso, por lo que la migración de las firmas puede venir después sin exponer las sesiones de ayer.

Paso 1: compruebe sus versiones y lo que negocian sus sesiones

Qué métodos admite el binario

ssh -V
ssh -Q kex
ssh -Q kex | grep mlkem

ssh -Q kex enumera los métodos de intercambio de claves compilados en el binario, con independencia de la configuración. Si aparece mlkem768x25519-sha256, la versión lo admite. Ambos extremos deben admitirlo, así que realice la misma comprobación en el servidor: un cliente moderno que se comunica con un servidor antiguo recurre a lo que ambos tengan en común.

Qué método ha usado esta sesión

ssh -v user@server 2>&1 | grep -i 'kex: algorithm'

La salida detallada se envía a la salida de error estándar, de ahí la redirección. Una sesión que usa el método híbrido muestra una línea del tipo debug1: kex: algorithm: mlkem768x25519-sha256. Es la comprobación más útil de todas, porque informa de lo que se ha negociado y no de lo que usted cree haber configurado.

Cuál es la configuración efectiva

ssh -G server | grep -i kexalgorithms
sudo sshd -T | grep -i kexalgorithms

ssh -G muestra la configuración del cliente que se aplicaría a ese destino, una vez resueltos todos los bloques Host y las inclusiones. sshd -T muestra la configuración efectiva del servidor y requiere privilegios de root. Ejecute ambos antes de cambiar nada y conserve la salida: es una evidencia de inventario.

Cronología de versiones

Fuente: las notas de versión de OpenSSH. Lectura práctica: a partir de la 9.9 ya dispone del método, a partir de la 10.0 se prefiere automáticamente y, entre la 9.0 y la 9.9, sigue teniendo un acuerdo de claves poscuántico mediante sntrup761x25519-sha512@openssh.com.

Paso 2: dar preferencia a mlkem768x25519-sha256 sin romper la compatibilidad con equipos antiguos

La directiva es KexAlgorithms, que se usa en ssh_config en el lado del cliente y en sshd_config en el lado del servidor. Admite tres prefijos: ^ antepone los métodos indicados a la lista por defecto integrada, + los añade al final y - los elimina. Anteponer es la opción segura, porque el resto de la lista por defecto se mantiene como alternativa.

Cliente, en ~/.ssh/config o en un archivo complementario en /etc/ssh/ssh_config.d/:

Host *
    KexAlgorithms ^mlkem768x25519-sha256

Servidor, en /etc/ssh/sshd_config o en un archivo complementario en /etc/ssh/sshd_config.d/:

KexAlgorithms ^mlkem768x25519-sha256

Si prefiere una lista ordenada explícita, mantenga los métodos clásicos al final para que los equipos que aún no se hayan actualizado puedan seguir conectándose:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

Valide la configuración antes de recargarla, y recargue en lugar de reiniciar:

sudo sshd -t
# the service name varies by distribution: ssh on Debian and Ubuntu, sshd on many others
sudo systemctl reload sshd

Un orden de operaciones que evita quedarse sin acceso: pruebe primero en preproducción, mantenga abierta una sesión con privilegios mientras recarga y, después, abra una segunda sesión y repita la comprobación con ssh -v antes de cerrar la primera. No elimine los métodos clásicos de la lista de un servidor hasta haber inventariado todos los clientes que se conectan a él: los hosts de salto, los ejecutores de automatización, los agentes de copia de seguridad, las sondas de monitorización, los dispositivos de red y las bibliotecas SSH embebidas son la causa habitual de las interrupciones en este punto.

Paso 3: interpretar correctamente el aviso de OpenSSH 10.1

OpenSSH 10.1 (6 de octubre de 2025) muestra un aviso cuando una conexión negocia un acuerdo de claves no poscuántico. La opción es WarnWeakCrypto y está activada por defecto. Hay dos puntos importantes para la operación.

En primer lugar, se trata de un aviso y no de un bloqueo: la conexión se completa igualmente. Le indica que el otro extremo de la conexión es la parte que requiere atención. En segundo lugar, sntrup761x25519-sha512@openssh.com es en sí mismo un híbrido poscuántico, por lo que una sesión que lo negocia no es el caso al que se dirige este aviso. Simplemente no se basa en un estándar del NIST, y por eso ML-KEM es la dirección que se sigue en materia de interoperabilidad y de requisitos de contratación.

Trate cada aviso como una línea de inventario: qué equipo remoto, qué versión y qué equipo humano es responsable de él. Si más adelante desea rechazar los intercambios exclusivamente clásicos en lugar de limitarse a avisar, defina una lista KexAlgorithms explícita que contenga solo métodos poscuánticos, y hágalo únicamente cuando sus comprobaciones demuestren que todos los equipos remotos los admiten.

Paso 4: las claves de host siguen siendo clásicas por ahora

En SSH, el acuerdo de claves y la autenticación se negocian por separado. Las claves de host y las claves de usuario son algoritmos de firma: ssh-ed25519, rsa-sha2-256, rsa-sha2-512 y las variantes de ECDSA. Las versiones anteriores cambiaron el acuerdo de claves, no los tipos de clave de host, por lo que la situación realista hoy es un intercambio híbrido que protege una sesión que sigue autenticándose con una clave de host clásica. Puede ver cuál se ha usado en la misma salida detallada:

ssh -v user@server 2>&1 | grep -i 'host key'

Esa situación intermedia es aceptable por la razón expuesta antes: la falsificación de firmas exige un ataque durante la conexión y no expone las sesiones grabadas en el pasado. El NIST normalizó ML-DSA como FIPS 204 el 13 de agosto de 2024 (consulte la página de ML-DSA), y la migración de las firmas en SSH depende de un trabajo adicional en el protocolo y en las implementaciones. Hasta entonces, registre esta carencia en lugar de ocultarla, prefiera claves de host ed25519 y, cuando se use RSA, siga las recomendaciones de tamaño de clave aplicables a su organización.

Qué registrar para auditorías e inventarios

SSH suele faltar en inventarios criptográficos que ya cubren TLS correctamente. El requisito 12.3.3 de PCI DSS v4.0.1 exige que los conjuntos de cifrado y los protocolos en uso se documenten y revisen al menos cada 12 meses, y es obligatorio desde el 31 de marzo de 2025 (consulte PCI DSS v4.0.1). En el marco de DORA, el artículo 6 del Commission Delegated Regulation (EU) 2024/1774 exige una política de cifrado y controles criptográficos que incluya disposiciones para actualizar o cambiar la tecnología criptográfica en función de la evolución del criptoanálisis, y su artículo 7 exige la gestión de claves a lo largo de todo su ciclo de vida (consulte la página de las RTS de DORA). Lo que esos textos exigen literalmente es la política y el inventario. La correspondencia siguiente es nuestra interpretación de cómo aportar evidencias para SSH, no una cita de ningún requisito. Esto es información, no asesoramiento jurídico.

Siguiente paso: compruebe el resto de su superficie

SSH es un protocolo entre varios, y la misma construcción híbrida existe en TLS como X25519MLKEM768. La forma más rápida de ver en qué situación se encuentran sus servicios públicos es analizar su dominio con PQC Status, que informa de los grupos de intercambio de claves negociados, las versiones de TLS y la cadena de certificados. Combine ese resultado con las comprobaciones SSH anteriores, una línea por host, y tendrá el comienzo de un inventario criptográfico real en lugar de una suposición.