Migrar SSH a criptografía post-cuántica: guía práctica

Actualizado: 2026-05-03

OpenSSH 9.9, publicada en septiembre de 2024, cerró una transición prometida durante años: soporte nativo de criptografía post-cuántica híbrida en el intercambio de claves SSH. Con un año de rodaje, clientes actualizados en la mayoría de distribuciones y bastantes empresas empezando a planificar la migración, este post recoge los pasos concretos y las decisiones que evitan sorpresas.

Puntos clave

• El riesgo que justifica migrar ya no es un ataque cuántico hoy, sino el ataque almacenar ahora, descifrar después.
• OpenSSH 9.9 añade mlkem768x25519-sha256; la 10.0 lo convierte en el intercambio por defecto cuando ambos extremos lo soportan.
• La configuración correcta lista el algoritmo híbrido primero y mantiene curve25519-sha256 como fallback para clientes antiguos.
• Las claves de host Ed25519 existentes siguen siendo válidas; las firmas post-cuánticas (ML-DSA) aún no han llegado a OpenSSH.
• Verificar el algoritmo activo con ssh -v es el paso más ignorado y el más necesario.

Por qué migrar ahora

La razón de migrar SSH a post-cuántica no es que un ordenador cuántico vaya a romper la conexión mañana. La razón es el ataque almacenar ahora, descifrar después: un adversario que capture el tráfico SSH hoy puede archivarlo y, cuando aparezca un ordenador cuántico capaz de romper Diffie-Hellman o ECDH, descifrar retroactivamente toda la sesión.

Este riesgo no aplica igual a todos. Para SSH de uso cotidiano a servidores de un hobby personal, la probabilidad de ser objetivo de almacenamiento selectivo es baja. Para infraestructura corporativa, financiera o sanitaria donde circulan secretos con horizonte largo, el cálculo cambia. La recomendación del NIST desde 2024 es migrar en cualquier comunicación con datos sensibles a largo plazo, empezando ya.

Qué trae OpenSSH 9.9 y 10.0

La novedad clave de la 9.9 es el soporte nativo de ML-KEM-768, el estándar post-cuántico basado en CRYSTALS-Kyber seleccionado por el NIST. La implementación es híbrida: combina ML-KEM con X25519, de forma que la sesión es segura si al menos uno de los dos algoritmos resiste. Si ECDH cae mañana porque aparece un ordenador cuántico, ML-KEM protege. Si se descubre un fallo en ML-KEM, X25519 protege.

OpenSSH 10.0, publicada en abril de 2025, hace mlkem768x25519-sha256 el intercambio por defecto cuando ambos extremos lo soportan. Si servidor y cliente corren la 10.0, el modo híbrido se activa sin configuración adicional. La línea de log KEX algorithm: mlkem768x25519-sha256 confirma la protección activa.

Pasos concretos de migración

Paso 1: actualizar OpenSSH a 9.9 o 10.0 en servidores y clientes:

• Debian 13 Trixie: OpenSSH 9.9 en repositorios por defecto.
• Ubuntu 24.04 LTS: vía actualización de seguridad.
• macOS: Homebrew ofrece una versión reciente (el OpenSSH de sistema va por detrás).
• Windows 11: integrado alcanzó 9.5 en 24H2; la 10.0 está en 25H1.

Paso 2: ajustar sshd_config para priorizar algoritmos híbridos sin romper compatibilidad:

KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256

El orden importa: clientes modernos usan PQC automáticamente, los que no lo soportan siguen conectando con ECDH.

Paso 3: verificar que la sesión híbrida funciona realmente. Desde un cliente moderno, ssh -v servidor y buscar la línea KEX algorithm en los logs. Debe mostrar mlkem768x25519-sha256. Si muestra curve25519-sha256, uno de los extremos no soporta PQC y la protección no está activa. La diferencia es silenciosa: la conexión funciona igual pero el cifrado post-cuántico no está activado.

Qué romper y qué no romper

Los riesgos principales de una migración mal hecha:

• Clientes OpenSSH anteriores a 8.5 no soportan ni sntrup761 ni ML-KEM. Si sshd_config exige solo PQC, esos clientes no pueden conectar. Mantener curve25519-sha256 como fallback resuelve esto.
• Gestores de configuración (Ansible, Puppet, Chef) pueden tener plantillas con KexAlgorithms heredadas de hace años que sobreescriben la configuración sin avisar. Revisar el estado real con ssh -Q kex en el servidor es la verificación definitiva.
• Bastion y jump hosts: una sesión con dos saltos SSH solo es post-cuántica si cada salto lo es. Si el bastion corre la 8.9 aunque el servidor final tenga la 10.0, el primer tramo no está protegido. La migración debe cubrir toda la cadena.

El contexto de criptografía post-cuántica para TLS sigue un patrón similar, documentado en PQC y TLS: estado de la adopción. La estrategia de auditoría de cadena de suministro que cubre dependencias criptográficas aparece en SBOM y CycloneDX para cadena de suministro.

Impacto en rendimiento

El intercambio de claves PQC híbrido es más caro que el clásico, pero solo en el handshake inicial:

• Latencia adicional en el handshake: 5-15 ms en una máquina moderna (imperceptible para sesiones interactivas).
• Tamaño del handshake: ML-KEM 768 incluye claves públicas de 1 184 bytes frente a los 32 bytes de X25519. Un handshake híbrido envía unos 2 KB más que uno clásico.
• Para herramientas que abren cientos de conexiones SSH por segundo (backups masivos, Ansible a gran escala), el coste agregado puede ser visible y conviene medir.

Verificación final y automatización

Tras la migración, la verificación tiene tres componentes:

1. ssh -Q kex en el servidor: debe incluir mlkem768x25519-sha256.
2. ssh -v en un cliente real: la línea KEX algorithm debe mostrar el algoritmo híbrido.
3. Auditoría periódica del sshd_config para detectar cambios accidentales.

Un test automatizado en CI que intente conectar forzando solo mlkem768 detecta cualquier regresión antes de que alguien lo note manualmente. Es un script de cinco líneas con un impacto real.

Mi lectura

La migración a SSH híbrido es razonable para cualquier servidor con información valiosa a largo plazo. El coste es unos minutos de configuración y un pequeño riesgo de romper clientes antiguos, mitigado con el fallback clásico. La ganancia es protección contra una amenaza que crece cada año.

Lo que hace educativa esta migración es que introduce en la rutina operativa el concepto de algoritmo híbrido. Durante los próximos años otros protocolos harán transiciones similares: TLS, IPsec, VPN. Los detalles cambian, pero el patrón es el mismo: adoptar el nuevo algoritmo en modo híbrido, verificar que funciona, eliminar el clásico solo cuando la compatibilidad esté asegurada. SSH es el mejor lugar para practicar ese patrón ahora, antes de tener que aplicarlo a toda la pila a la vez.