Valores poscuánticos predeterminados de OpenSSH y advertencia de intercambio de claves no poscuántico

Objetivo

Estado al 25 de octubre de 2026. Resolver una advertencia de intercambio de claves no poscuántico comprobando los extremos reales y sus ajustes. Volver a consultar las orientaciones poscuánticas de OpenSSH, la documentación del paquete instalado y la configuración efectiva antes de cambiar la política. Los hitos de versiones siguientes describen funciones del proyecto original, no el nivel de parches de seguridad más reciente.

Las orientaciones de OpenSSH indican un valor poscuántico predeterminado desde 9.0, inicialmente con el híbrido sntrup. El soporte de mlkem768x25519-sha256 llegó en 9.9 y pasó a ser el predeterminado en 10.0. OpenSSH 10.1, publicado el 6 de octubre de 2025, introdujo una advertencia cuando una conexión selecciona un intercambio no poscuántico.

Requisitos previos

Disponer de una cuenta de prueba autorizada, acceso a la configuración de ambos extremos y una sesión administrativa existente o una consola para recuperación. La advertencia se refiere a la protección frente al descifrado futuro del tráfico registrado. Por sí sola no demuestra que se haya interceptado el tráfico, que un sistema esté comprometido ni que haya fallado la comprobación de la clave del host.

Pasos

1. Identificar la implementación real de SSH en cada extremo, incluidos los dispositivos especializados y los servicios Git integrados. Ejecutar ssh -V en el cliente. Un paquete con un nombre parecido o la versión del cliente no permiten determinar qué admite un servicio remoto.

2. Inspeccionar las capacidades locales con ssh -Q kex y, después, los ajustes que se aplican al destino real:

   ssh -G server.example
   

   Revisar kexalgorithms y los ajustes específicos del host que correspondan. La consulta de algoritmos admitidos no es la lista efectiva de algoritmos permitidos, y ninguna de las dos es el resultado negociado.

3. En un servidor OpenSSH, utilizar sshd -T con privilegios suficientes para inspeccionar la configuración efectiva. Utilizar sus parámetros de conexión -C cuando sea necesario evaluar ajustes condicionales pertinentes. Revisar los archivos incluidos y las restricciones gestionadas de forma centralizada antes de editar nada.

4. Dar preferencia a las actualizaciones con soporte del proveedor y a la eliminación de restricciones obsoletas que excluyan los algoritmos híbridos. Los extremos más antiguos pueden anunciar sntrup761x25519-sha512@openssh.com; las notas de la versión 9.9 añaden expresamente el nombre sin sufijo sntrup761x25519-sha512. Esta descripción es más precisa que la denominación abreviada del resumen sobre criptografía poscuántica. Un extremo que utilice el híbrido anterior no tiene por qué clasificarse como exclusivamente clásico solo porque carezca de ML-KEM. Confirmar los nombres exactos aceptados por cada compilación.

5. Validar la configuración editada del servidor con sshd -t antes de utilizar el procedimiento habitual de recarga de la plataforma. Mantener abierta la sesión de recuperación. Establecer una conexión separada sin reutilizar una sesión multiplexada:

   ssh -vv -S none server.example
   

   Leer el algoritmo de intercambio de claves seleccionado en la salida de diagnóstico y verificar la autenticación habitual del host y el inicio de sesión. Cerrar la sesión de prueba al terminar. Evitar publicar registros de diagnóstico sin ocultar los nombres de host o los datos de cuentas que contengan.

6. Si todavía no se puede actualizar un extremo antiguo, documentar su responsable, la sensibilidad de los datos y el plan de sustitución. Mantener visible la advertencia salvo que sea necesaria una excepción revisada y de alcance limitado. Silenciar WarnWeakCrypto cambia los avisos; no mejora la criptografía.

Resultado esperado

Una conexión nueva selecciona un intercambio híbrido permitido o se mantiene una excepción para sistemas antiguos registrada expresamente. Los clientes existentes siguen conectándose como estaba previsto y se sigue exigiendo la verificación de la clave del host.

Límites y base de verificación

Este procedimiento se basa en la documentación del proyecto original, no en pruebas de un conjunto de equipos. Los paquetes y las políticas de los distribuidores pueden diferir. No desactivar las comprobaciones estrictas de claves de host, eliminar controles de autenticación ni sustituir las claves de usuario solo para resolver una advertencia de intercambio de claves. Un intercambio híbrido correcto aporta pruebas sobre el acuerdo de claves de esa conexión, no demuestra que todos los mecanismos de autenticación sean poscuánticos.