Advertencia poscuántica en SSH: qué significa y cómo diagnosticarla
Te conectas por SSH, entras al servidor y aparece una advertencia sobre criptografía poscuántica. La sesión funciona, pero el cliente avisa que el intercambio de claves negociado no está diseñado para resistir un futuro ataque cuántico. Es un mensaje que merece atención, especialmente si por esa conexión pasan datos que deben seguir siendo confidenciales durante años.
El aviso llegó a OpenSSH en la versión 10.1. Su explicación oficial habla de store now, decrypt later: un adversario podría guardar hoy tráfico cifrado e intentar descifrarlo en el futuro con una computadora cuántica suficientemente capaz. Eso no significa que alguien haya descifrado tu sesión actual. Significa que hay que conocer el algoritmo negociado y planear la actualización.
El tema volvió a primer plano porque NIST publicó el 27 de octubre de 2026 su informe final IR 8547, una hoja de ruta para pasar de algoritmos vulnerables a estándares poscuánticos. Aquí traduzco esa conversación a un tutorial de diagnóstico de SSH que no requiere cambiar la configuración del servidor a ciegas.
Qué está diciendo exactamente la advertencia
SSH usa un intercambio de claves para acordar el secreto que protege la sesión. También usa una clave de autenticación para demostrar quién eres y una clave de host para identificar al servidor. Son piezas diferentes. Cambiar el archivo que pasas con -i no cambia, por sí mismo, el algoritmo de intercambio de claves que negocian cliente y servidor.
OpenSSH explica que el aviso aparece cuando la sesión termina usando un intercambio de claves no poscuántico. Sus opciones híbridas recomendadas incluyen mlkem768x25519-sha256 y sntrup761x25519-sha512. «Híbrido» significa que combinan un componente poscuántico con uno clásico. OpenSSH ofrece una de estas opciones por defecto desde la versión 9.0; la otra llegó en la 9.9.
Tutorial: diagnostica una conexión en cuatro pasos
1. Comprueba tu cliente
ssh -V
ssh -Q kex | grep -E 'mlkem768x25519|sntrup761x25519'
La primera línea muestra la versión local. La segunda enumera si tu cliente conoce esos algoritmos. No prueba qué algoritmo usó una conexión concreta: para eso hace falta inspeccionar la negociación.
2. Observa el algoritmo negociado
ssh -vv -o BatchMode=yes -p 22 usuario@servidor true 2>&1 | grep 'kex: algorithm:'
Sustituye usuario, servidor y puerto por los de un sistema que administras. Busca una línea como kex: algorithm: curve25519-sha256 o kex: algorithm: mlkem768x25519-sha256. El primer ejemplo es clásico; el segundo es híbrido poscuántico. BatchMode=yes evita pedir una contraseña durante esta comprobación. Si el servidor requiere otra forma de autenticación, la prueba puede terminar sin iniciar sesión aunque ya haya mostrado la negociación. No publiques el registro completo de depuración: puede revelar detalles de tu infraestructura.
3. Distingue capacidad de configuración
Si tu cliente ofrece un algoritmo híbrido pero la sesión usa uno clásico, revisa la versión y la configuración del servidor con el proveedor o administrador. La FAQ de OpenSSH recomienda actualizar el servidor a una implementación compatible y comprobar si KexAlgorithms ha deshabilitado las opciones poscuánticas. En alojamiento compartido, es habitual que solo el proveedor pueda modificar sshd.
4. Planea el cambio y prueba el acceso
Antes de alterar SSH en producción, identifica todos los clientes: laptops, tareas programadas, respaldos, integración continua y herramientas de soporte. Prueba la configuración en un entorno de ensayo, conserva una vía de recuperación y verifica que los clientes legítimos siguen conectando. Después repite el paso 2 para confirmar el algoritmo realmente negociado.
Qué priorizar en la organización
No todas las sesiones tienen la misma exposición futura. Prioriza conexiones por las que viajen secretos, datos personales, respaldos o información con una vida útil larga. Registra servidor, proveedor, versión, algoritmo observado, dueño y fecha de revisión. La guía de migración de NIST pone el inventario criptográfico en el centro de la preparación: además de SSH, hay que localizar TLS, VPN, certificados y dependencias de terceros.
El aviso de SSH no es un diagnóstico de toda la seguridad del servidor. Una conexión híbrida tampoco corrige credenciales expuestas, software sin parches o permisos excesivos. Su valor está en señalar una deuda criptográfica concreta que puede medirse y asignarse.
Preguntas frecuentes
¿Debo cambiar mi llave Ed25519?
La advertencia descrita aquí se refiere al intercambio de claves de la sesión, no al nombre de tu llave de acceso. Las firmas y claves de autenticación también forman parte de la transición poscuántica, pero OpenSSH distingue sus plazos y riesgos del problema de guardar tráfico hoy para descifrarlo después.
¿Puedo quitar el aviso?
OpenSSH permite controlar la advertencia con WarnWeakCrypto. Esa opción solo cambia el mensaje que ves, no la protección negociada. Documenta primero el algoritmo, el riesgo y el plan de actualización; así sabrás si una excepción temporal está justificada.
¿Hay una computadora cuántica rompiendo SSH ahora?
OpenSSH indica que aún no existe una computadora cuántica con la capacidad criptográfica relevante para este ataque. La preparación se adelanta porque los datos interceptados hoy pueden conservar valor cuando la tecnología avance.
Mi recomendación para dirección de tecnología es tratar este mensaje como una señal medible: descubre dónde ocurre, identifica quién puede corregirlo y prioriza según la vida útil de la información. La migración poscuántica empieza con visibilidad y pruebas de interoperabilidad, no con una configuración copiada a todos los servidores.
Fuentes: OpenSSH: Post-Quantum Cryptography; NIST IR 8547, Transition to Post-Quantum Cryptography Standards; NIST NCCoE, Migration to PQC.
