SSH seguro para computación cuántica: opciones de migración para el acceso empresarial

Respuesta rápida: El intercambio de claves de SSH es compatible con la computación cuántica desde OpenSSH 9.0 en abril de 2022, primero mediante el híbrido sntrup761x25519-sha512 y luego mediante el híbrido mlkem768x25519-sha256 estandarizado por NIST, que se convirtió en el predeterminado en OpenSSH 10.0. Un cliente OpenSSH actual que se conecta a un servidor actual ya negocia un intercambio de claves resistente a la computación cuántica sin necesidad de configuración. Las claves de host y de autenticación de usuario son un caso aparte: Las claves de host y de usuario de SSH siguen siendo clásicas (Ed25519 o RSA) hoy en día, ya que la estandarización de firmas para computación cuántica en SSH aún está en desarrollo en el IETF. Esta guía cubre qué migrar ahora, qué esperar y cómo crear el inventario y el plan de reversión en torno a servidores intermedios y automatización.

SSH es uno de los casos de éxito más discretos de la era poscuántica: su intercambio de claves ha sido resistente a la computación cuántica, por defecto, durante más tiempo del que la mayoría de las organizaciones se dan cuenta. Lo que realmente requiere planificación no es el intercambio de claves, sino la autenticación de claves de host y usuario, que sigue siendo completamente clásica y aún no cuenta con estándares definidos. Esta guía distingue claramente entre ambos aspectos.

Puntos Clave

• OpenSSH incluye de forma predeterminada el intercambio de claves híbrido post-cuántico desde la versión 9.0 (abril de 2022), inicialmente a través de sntrup761x25519-sha512.
• OpenSSH 9.9 añadió el algoritmo híbrido mlkem768x25519-sha256, estandarizado por el NIST, que se convirtió en el predeterminado en OpenSSH 10.0 (abril de 2025).
• OpenSSH 10.1 comenzó a advertir a los usuarios cuando una conexión negocia un intercambio de claves que no sea post-cuántico, lo que indica que el ecosistema ahora trata el intercambio de claves exclusivamente clásico como la excepción, no la norma.
• Las claves de host y las claves de autenticación de usuario siguen siendo clásicas (Ed25519 o RSA); la estandarización de firmas post-cuánticas para la autenticación SSH aún está en curso en el IETF.
• El algoritmo híbrido sntrup761x25519-sha512 fue estandarizado formalmente como RFC 9941 en abril de 2026, lo que le otorgó al algoritmo híbrido anterior, previo al NIST, una base de estándares sólida junto con la opción más reciente ML-KEM.

Intercambio de claves: ya resuelto para el software actual.

El intercambio de claves SSH se ha adelantado discretamente a la mayoría de los protocolos en la migración post-cuántica. OpenSSH 9.0 incluyó el algoritmo híbrido sntrup761x25519-sha512, que combina Streamlined NTRU Prime con el clásico X25519, como algoritmo de intercambio de claves predeterminado en abril de 2022, años antes de que el NIST finalizara ML-KEM. OpenSSH 9.9 añadió mlkem768x25519-sha256, que combina el ahora estandarizado ML-KEM-768 con X25519, y OpenSSH 10.0 lo convirtió en el nuevo algoritmo predeterminado en abril de 2025. A partir de OpenSSH 10.1, conectarse sin negociar uno de estos algoritmos híbridos post-cuánticos activa una advertencia explícita: "Esta sesión puede ser vulnerable a ataques de almacenamiento y descifrado posterior".

El resultado práctico: un cliente OpenSSH actual que se conecta a un servidor OpenSSH actual negocia automáticamente el intercambio de claves resistente a la computación cuántica, sin necesidad de configuración. El híbrido sntrup761x25519-sha512 también obtuvo reconocimiento oficial como estándar en abril de 2026 como RFC 9941, y un borrador paralelo del grupo de trabajo SSHM de la IETF está definiendo el estándar equivalente para el híbrido ML-KEM.

La automatización del ciclo de vida y el inventario de claves SSH para este tipo de entorno es precisamente donde encaja SSH Secure , ya que permite descubrir las claves en todos sus servidores y sistemas de automatización antes de que una fecha límite de migración obligue a realizar una auditoría apresurada.

Claves de host y de usuario: La parte que aún espera la estandarización

Esta es la distinción más importante para la planificación. La autenticación de clave de host SSH, el mecanismo que prueba que un servidor es quien dice ser, y la autenticación de clave de usuario, el mecanismo que prueba la identidad de un cliente, aún dependen por completo de algoritmos clásicos: Ed25519 o RSA. Ninguno de ellos tiene un reemplazo poscuántico finalizado en la rama principal de OpenSSH, y la estandarización de firmas basadas en ML-DSA para SSH aún se encuentra en una etapa temprana en el IETF.

Se trata de una secuencia deliberada, no de un descuido, y sigue la misma lógica que se describe en nuestro marco de decisión PQC híbrido : el intercambio de claves se asemeja a un cambio de biblioteca autónomo, mientras que la migración de firmas abarca un ámbito mucho más amplio: herramientas de generación y distribución de claves, flujos de trabajo de verificación de claves del host y cualquier script de automatización que actualmente espere un formato de clave Ed25519 o RSA.

Compatibilidad con OpenSSH en diversas plataformas

El momento de la compatibilidad varía según la distribución. Red Hat Enterprise Linux 10 se lanzó con OpenSSH 9.9, y RHEL 10.1 estableció mlkem768x25519-sha256 como la opción predeterminada preferida, a menos que se configurara explícitamente de otra manera. RHEL 10.2 fue más allá, agregando opciones híbridas compatibles con FIPS, mlkem768nistp256-sha256 y mlkem1024nistp384-sha384, a través de parches posteriores, ya que los mantenedores de OpenSSH optaron por no implementar directamente variantes de curvas NIST. Las organizaciones que operan bajo los requisitos FIPS deben confirmar qué híbrido específico admite su plataforma y distribución, ya que el cumplimiento de FIPS depende de la combinación exacta de curva y hash, no solo de la "compatibilidad post-cuántica" como una afirmación general.

No todas las implementaciones de clientes SSH se han actualizado. Algunos clientes SSH integrados o incorporados, especialmente en dispositivos de red antiguos o herramientas especializadas, aún no admiten el intercambio de claves post-cuánticas, lo que hace que un inventario de las versiones reales del cliente, y no solo de las del servidor, sea un paso esencial antes de asumir que un entorno está completamente cubierto.

Hosts de salto, automatización e inventario

La complejidad operativa de SSH dificulta su detección en comparación con una migración TLS típica. Las claves y las relaciones de confianza suelen estar integradas en lugares que no aparecen en un inventario de servidores simple: configuraciones de servidores intermedios que encadenan múltiples saltos SSH, credenciales de canalizaciones de CI/CD, herramientas de infraestructura como código que aprovisionan acceso SSH mediante programación y scripts de automatización de larga duración con huellas digitales de claves de host o rutas de archivos de clave codificadas.

Crear un inventario preciso implica abarcar todos estos aspectos, no solo las sesiones interactivas de los usuarios: cada servidor intermedio y las cadenas de saltos que dependen de él, cada proceso automatizado que establece una conexión SSH y cada referencia codificada a un algoritmo de clave o formato de archivo específico que una futura migración de clave de host podría romper.

Consideraciones sobre la reversión

La reversión del intercambio de claves es de bajo riesgo por diseño: fijar un orden de preferencia específico para KexAlgorithms, con los algoritmos clásicos listados como entradas de reserva, permite que un entorno se adapte sin problemas a pares más antiguos, al tiempo que sigue prefiriendo el híbrido post-cuántico siempre que ambas partes lo admitan. La reversión de la clave del host, una vez que las opciones de firma post-cuántica se estandaricen y se implementen, tendrá mayor peso operativo, ya que los cambios de clave del host activan advertencias de hosts conocidos y pueden interrumpir la automatización que fija huellas digitales de clave específicas. Por eso mismo, vale la pena crear el host intermedio y el inventario de automatización ahora, antes de esa migración, antes de que la presión de una fecha límite lo obligue.

Lo que realmente recomendamos

Actualice ahora mismo todos sus servidores y clientes a la versión más reciente de OpenSSH; la ventaja del intercambio de claves resistente a la computación cuántica es inmediata y no requiere ninguna decisión adicional una vez que el software esté actualizado. Asigne explícitamente a KexAlgorithms las opciones híbridas post-cuánticas preferidas y clásicas como alternativa, en lugar de depender de valores predeterminados implícitos que varían según la versión. Cree ahora el inventario de hosts intermedios y automatización, mientras las claves de host aún son clásicas y estables, para que la migración de claves de host eventual cuente con un mapa preciso sobre el cual trabajar en lugar de comenzar desde cero bajo la presión de los plazos.

Cómo puede ayudar la consultoría de cifrado

Las cadenas de servidores intermedios, los scripts de automatización y las referencias de claves codificadas que hacen que la migración SSH sea más difícil de lo que parece son precisamente la brecha de descubrimiento que SSH Secure , la plataforma dedicada a la gestión de claves SSH de Encryption Consulting, está diseñada para cerrar, descubriendo e inventariando las claves SSH en servidores, servidores intermedios y herramientas de automatización, y automatizando el ciclo de vida de las claves para que la migración final de claves de host comience desde un inventario real y actual en lugar de la memoria institucional.

Nuestros servicios de asesoramiento sobre PQC incorporan ese inventario a un plan de migración ahora mismo, secuenciando la actualización inmediata de OpenSSH y el trabajo de configuración de KexAlgorithms en función de la futura migración de claves de host, para que su organización esté preparada para actuar con rapidez una vez que se finalicen los estándares de firma SSH post-cuánticos, en lugar de comenzar el proceso de descubrimiento desde cero en ese momento.

Un problema resuelto, otro pendiente.

El intercambio de claves SSH ha sido resistente a la computación cuántica por defecto durante años, y la única medida que la mayoría de las organizaciones deben tomar es asegurarse de que su versión de OpenSSH esté actualizada. La autenticación de claves de host y usuario es el trabajo restante, y aún no se puede abordar de la misma manera, ya que los estándares en los que se basa no se han finalizado. Las organizaciones que avanzarán más rápido cuando esto suceda serán aquellas que estén creando ahora un mapa preciso de servidores intermedios, automatización y dependencias de claves, antes de que exista la presión de un plazo que obligue a realizar un inventario apresurado más adelante.

Preguntas frecuentes

¿SSH ya es resistente a la computación cuántica?

En las versiones actuales de OpenSSH, el intercambio de claves viene activado por defecto desde la versión 9.0. La clave de host y la autenticación de usuario no lo están; ambas siguen utilizando el método clásico Ed25519 o RSA a la espera de la estandarización de las firmas SSH post-cuánticas por parte de la IETF.

¿Necesito hacer algo para obtener el intercambio de claves SSH post-cuántico?

Si tanto el cliente como el servidor ejecutan OpenSSH 9.0 o posterior, el intercambio de claves híbrido post-cuántico se negocia automáticamente sin necesidad de configuración. Al ejecutar OpenSSH 10.0 o posterior, se utiliza por defecto el intercambio de claves híbrido ML-KEM estandarizado por NIST, en lugar del anterior intercambio híbrido sntrup761.

¿Por qué la autenticación mediante clave de host SSH aún no ha adoptado algoritmos post-cuánticos?

La estandarización de firmas basadas en ML-DSA para SSH aún se encuentra en una fase inicial en el IETF. Esto refleja la tendencia general de que el intercambio de claves migra más rápidamente que las firmas, ya que la migración de firmas afecta a los flujos de trabajo de generación, distribución y verificación de claves en todo un entorno, en lugar de limitarse a una única actualización de la biblioteca.

¿Qué deben hacer las organizaciones ahora si las claves de host no están listas para migrar?

Cree ahora un inventario de servidores intermedios, canalizaciones de automatización y referencias de claves codificadas. Este es el trabajo de investigación que requerirá una futura migración de claves de host, independientemente del estándar que finalmente se adopte, y hacerlo antes de la fecha límite evita un inventario apresurado e incompleto más adelante.

¿Influye el cumplimiento de la norma FIPS en la elección de la opción de intercambio de claves SSH post-cuántica que se debe utilizar?

Sí. Los entornos compatibles con FIPS requieren las variantes híbridas específicas de la curva NIST, como mlkem768nistp256-sha256, en lugar de las híbridas basadas en X25519 que OpenSSH incluye por defecto. Confirme qué variante admite su plataforma y distribución específicas antes de asumir que la compatibilidad general con la computación poscuántica cumple con los requisitos de FIPS.