SSH poscuántico en Ubuntu: qué cambió realmente

Qué cambió en SSH poscuántico

SSH poscuántico ya está activado para la mayoría de los usuarios y nadie tuvo que configurarlo. Un cliente OpenSSH actual que se conecta a un servidor OpenSSH actual selecciona de forma predeterminada un intercambio de claves poscuántico híbrido. Por tanto, la clave de sesión resiste a un atacante que registre el tráfico hoy y lo descifre dentro de varios años. La protección es real, pero su alcance es más limitado de lo que sugiere la expresión «SSH resistente a la computación cuántica».

Primero, dos términos. SSH (secure shell) es el protocolo que se utiliza para iniciar sesión en un servidor. El intercambio de claves, que normalmente se escribe «kex», es el primer paso de toda conexión SSH: ambos extremos acuerdan un secreto compartido y ese secreto cifra todo lo que sigue. El intercambio de claves es la parte que cambió. Todo lo demás sigue igual.

No confíe en esta página; ejecute los comandos

Todos los nombres de algoritmos que aparecen a continuación proceden de un comando que puede ejecutar usted mismo. Es intencionado. El valor predeterminado cambia con cada versión de OpenSSH. Por eso, una guía escrita hace dos años puede mencionar un algoritmo que su equipo ya no prefiere, sin tener forma de indicárselo. Aprenda estos comandos y dejará de necesitar artículos sobre este tema, incluido este.

Empiece por comprobar qué admite su compilación.

ssh -V
ssh -Q kex

ssh -V muestra una línea de versión que comienza por OpenSSH_, seguida del sufijo del paquete de Ubuntu y la versión de OpenSSL. ssh -Q kex muestra un algoritmo de intercambio de claves por línea. En una compilación con compatibilidad poscuántica, encontrará nombres como mlkem768x25519-sha256 y sntrup761x25519-sha512@openssh.com en esa lista, junto a nombres clásicos como curve25519-sha256.

Lo que admite su compilación no es lo mismo que ofrece

Esta es la distinción que omiten la mayoría de los artículos. ssh -Q kex responde a una pregunta: qué puede hacer este binario. No responde a la pregunta importante: qué propondrá realmente esta conexión. Las dos listas son diferentes, y la diferencia entre ellas es donde los consejos antiguos causan problemas reales.

ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'

ssh -G <host> muestra la configuración efectiva del cliente para ese host, después de aplicar ~/.ssh/config y /etc/ssh/ssh_config. sshd -T hace lo mismo para el servidor. Cada uno muestra una sola línea kexalgorithms en orden de preferencia, y el primer nombre de esa línea es la primera opción de ese lado. Esa línea es la que se envía por la red.

La diferencia no es teórica. OpenSSH 8.5, publicado el 2021-03-03, añadió sntrup761x25519-sha512@openssh.com y lo dejó deliberadamente fuera de la lista predeterminada. En esa versión, ssh -Q kex muestra el algoritmo y ssh -G no lo muestra, lo que significa que el binario puede realizar un intercambio de claves poscuántico, pero ninguna conexión lo solicita.

Lea el algoritmo negociado por su conexión

ssh -v example.com 2>&1 | grep 'kex: algorithm'

Entre un cliente actual y un servidor actual, se muestra lo siguiente:

debug1: kex: algorithm: mlkem768x25519-sha256

mlkem768x25519-sha256 es un algoritmo híbrido. Ejecuta ML-KEM (mecanismo de encapsulación de claves basado en retículos, estandarizado como FIPS 203) con el conjunto de parámetros 768, junto con Diffie-Hellman de curva elíptica X25519, y combina ambas salidas en la clave de sesión.

Con un servidor antiguo, puede ver esto:

debug1: kex: algorithm: curve25519-sha256

Ese nombre no tiene ningún componente poscuántico. curve25519-sha256 es Diffie-Hellman de curva elíptica por sí solo, y un ordenador cuántico grande puede romperlo. Esa es la razón del cambio del valor predeterminado.

Una regla de negociación explica por qué una sola máquina antigua puede limitar una sesión. El cliente envía su lista en orden de preferencia y el servidor envía la suya. El algoritmo seleccionado es el primer nombre de la lista del cliente que también aparece en la del servidor. La preferencia del cliente tiene prioridad, por lo que el extremo más antiguo de los dos determina hasta dónde se puede avanzar en la lista. Actualizar el portátil no actualiza una sesión con un servidor que nunca ha reconocido ML-KEM.

Elimine grep y ssh -v para ver el resto de la negociación, incluida la línea sobre la que trata la sección siguiente:

debug1: kex: host key algorithm: ssh-ed25519

¿Qué versión de OpenSSH convirtió el intercambio híbrido en la opción predeterminada?

Las notas de la versión del proyecto proporcionan una secuencia clara. Las fechas son más importantes que los números de versión porque muestran cuánto tiempo lleva funcionando de forma silenciosa.

• 8.5, publicada el 2021-03-03, añadió sntrup761x25519-sha512@openssh.com y la dejó deshabilitada de forma predeterminada.
• 9.0, publicada el 2022-04-08, la habilitó. Las notas indican que OpenSSH «usará de forma predeterminada el método de intercambio de claves híbrido Streamlined NTRU Prime + x25519». Esta es la versión en la que el intercambio de claves poscuántico pasó a ser el caso normal.
• 9.9, publicada el 2024-09-19, añadió mlkem768x25519-sha256 como segunda opción. La misma versión asignó al método anterior el nombre registrado por IANA, sntrup761x25519-sha512, por lo que las compilaciones más recientes lo muestran con ambas denominaciones.
• 10.0, publicada el 2025-04-09, convirtió mlkem768x25519-sha256 en la opción predeterminada para la negociación de claves.
• 10.1, publicada el 2025-10-06, añadió una advertencia del cliente cuando una conexión negocia un intercambio de claves sin componente poscuántico. La controla la opción WarnWeakCrypto en ssh_config y está habilitada de forma predeterminada.

Conviene recordar abril de 2022. Cualquier par de equipos que ejecute OpenSSH 9.0 o posterior lleva realizando desde entonces un intercambio de claves poscuántico, sin configuración adicional ni aviso para la persona que escribe ssh.

Qué versión de Ubuntu lo incluye

Ubuntu fija una versión de OpenSSH en cada release y después incorpora correcciones de seguridad mediante backports sin cambiar el número de versión. Por tanto, la release de Ubuntu que ejecuta determina el algoritmo predeterminado. Compruebe la máquina que tiene delante con ssh -V en lugar de confiar en una lista. En agosto de 2026, el archivo contiene estas versiones:

• 22.04 LTS incluye 1:8.9p1, anterior al valor predeterminado de 9.0, por lo que una instalación estándar negocia curve25519-sha256.
• 24.04 LTS incluye 1:9.6p1, posterior a 9.0 y anterior a 9.9, por lo que su valor predeterminado es sntrup761x25519-sha512@openssh.com y no incluye ML-KEM.
• 25.10 incluye 1:10.0p1, cuyo valor predeterminado es mlkem768x25519-sha256.
• 26.04 LTS incluye 1:10.2p1, cuyo valor predeterminado es mlkem768x25519-sha256 y que muestra una advertencia sobre las conexiones que no son poscuánticas.

Analice un par de máquinas reales. Un portátil con 26.04 se conecta a un servidor con 24.04. La primera opción del cliente, mlkem768x25519-sha256, no figura en la lista del servidor con 9.6. La siguiente opción poscuántica del cliente que el servidor sí admite es sntrup761x25519-sha512@openssh.com, y ese es el nombre que muestra ssh -v. El intercambio de claves de la sesión es poscuántico, aunque el servidor se compiló en 2024 y nadie configuró nada.

El caso de 22.04 funciona al contrario y muestra exactamente por qué ssh -Q kex por sí solo puede inducir a error. OpenSSH 8.9 conoce el nombre sntrup761x25519-sha512@openssh.com, por lo que ssh -Q kex lo muestra en ese equipo, pero la propuesta predeterminada lo excluye y la negociación termina usando curve25519-sha256. Desde un cliente OpenSSH 10.1 o posterior, la conexión lo indica:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

Esa advertencia describe el servidor al que se conecta, no el cliente. La solución es actualizar el servidor. Establecer WarnWeakCrypto no elimina el mensaje, pero no cambia la conexión.

Por qué usar un esquema híbrido y qué significa recopilar ahora y descifrar después

La amenaza es sencilla. Un atacante que puede ver el tráfico registra hoy los bytes cifrados y los almacena. Hoy no puede leerlos. Los conserva hasta que exista un ordenador cuántico suficientemente grande para romper X25519 y, entonces, los lee. Esto se denomina recopilar ahora y descifrar después, o almacenar ahora y descifrar después. En el presente no exige que el atacante haga nada sofisticado. Sólo necesita espacio en disco y paciencia.

El cifrado tiene este problema, pero las firmas no, y esta asimetría determina todo lo demás. Un texto cifrado registrado conserva su valor mientras los datos que contiene sigan siendo confidenciales. Una firma sólo tiene que ser imposible de falsificar en el momento en que se verifica. Romper un algoritmo de firma en 2035 permitiría a alguien suplantar un servidor en 2035. No le permitiría retroceder en el tiempo y falsificar un inicio de sesión de 2026. Por eso había que corregir primero el intercambio de claves; la parte de las firmas puede esperar.

Un esquema híbrido significa que se ejecutan ambos algoritmos y que ambos resultados contribuyen a la clave de sesión. Para recuperar el secreto detrás de mlkem768x25519-sha256, un atacante debe romper ML-KEM 768 y X25519. La combinación es deliberada: ML-KEM es mucho más reciente que X25519 y ha estado expuesto durante mucho menos tiempo al análisis de los criptoanalistas. Por tanto, un fallo descubierto en el algoritmo nuevo no elimina la protección que ya tenía.

Qué está protegido y qué no

El intercambio de claves está protegido. El secreto compartido que cifra la sesión procede de un intercambio híbrido, por lo que una grabación de esa sesión realizada hoy no podrá leerse cuando lleguen los ordenadores cuánticos.

La clave de host no está protegida. La línea debug1: kex: host key algorithm: ssh-ed25519 especifica una firma clásica, al igual que rsa-sha2-512 y los tipos ECDSA (algoritmo de firma digital de curva elíptica). Un atacante con un ordenador cuántico operativo podría falsificar esa firma e suplantar el servidor, pero sólo durante una conexión activa en ese momento futuro, nunca contra tráfico registrado ahora.

La clave de inicio de sesión tampoco está protegida. La clave de ~/.ssh/id_ed25519 es el mismo tipo de firma clásica, y el mismo razonamiento se aplica en este caso. Lo que protege esa clave este año es dónde se almacena y quién puede leerla, por lo que una gestión sensata de las claves SSH reduce mucho más el riesgo real que cualquier nombre de algoritmo de esta página.

No tiene que hacer nada con ninguna de esas claves, porque no hay ninguna alternativa a la que cambiar. OpenSSH ha indicado que la compatibilidad con firmas poscuánticas llegará en una versión futura. Hasta que se publique, OpenSSH no tiene ningún tipo de clave de host poscuántica ni ningún tipo de clave de usuario poscuántica, y ssh-keygen no puede ofrecerle ninguno. Una guía que le indique generar una está describiendo software que todavía no existe.

TLS en el mismo servidor es una cuestión independiente y tiene una respuesta distinta. TLS (seguridad de la capa de transporte) es el protocolo que utiliza su servidor web en el puerto 443, y se basa en un código distinto y un calendario de desarrollo diferente. Actualizar OpenSSH no cambia nada en ese caso. Si está utilizando un certificado autofirmado para un servicio privado en el mismo VPS, OpenSSL y su servidor web determinan su firma y su intercambio de claves, por lo que debe analizar esa pila por separado.

Qué hace ahora un operador sensato

Mantenga OpenSSH actualizado y no haga nada más. Esa es toda la estrategia para este problema. sudo apt update && sudo apt upgrade mantiene la versión incluida en su versión de Ubuntu, y actualizar a una versión más reciente de Ubuntu es lo que le proporciona una versión más reciente de OpenSSH. Activar las actualizaciones de seguridad desatendidas aplica esos parches sin que tenga que acordarse. Compilar OpenSSH desde el código fuente para buscar un nombre de algoritmo concreto es una mala compensación, porque pierde las actualizaciones de seguridad de la distribución para el servicio más expuesto del servidor. Si aun así descarga el código fuente, compruebe la descarga con la suma de comprobación publicada antes de compilarlo.

No escriba manualmente una línea KexAlgorithms. Esta es la única acción que empeora la situación de forma fiable. Una guía de endurecimiento de 2018 le entrega una lista que era correcta en 2018, y pegarla en sshd_config reemplaza la lista predeterminada en lugar de ampliarla. Ahora se excluye cualquier algoritmo inventado desde entonces, por lo que un servidor que habría negociado mlkem768x25519-sha256 por sí solo desciende silenciosamente al algoritmo que quede en la lista fijada. Ejecute sudo sshd -T | grep -i '^kexalgorithms' en cualquier servidor que haya heredado. Si esa línea es más corta que la de una instalación nueva de la misma versión, alguien la fijó manualmente.

Si tiene un motivo real para cambiar la lista, añada elementos en lugar de reemplazarla. OpenSSH interpreta un + inicial como una operación de anexión, un - inicial como una operación de eliminación y un ^ inicial como una operación para mover el elemento al principio.

KexAlgorithms ^mlkem768x25519-sha256

Pruebe el archivo antes de confiar en él. sudo sshd -t analiza la configuración y no muestra nada cuando es válida. Una línea KexAlgorithms que nombre un algoritmo que la compilación no incluye impide que sshd se inicie. En un servidor remoto, eso significa que no podrá volver a acceder, así que mantenga abierta una segunda sesión mientras trabaja. Cuando las listas de ambos extremos dejan de tener elementos en común, el cliente lo indica claramente:

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

Interprete el marketing sobre la seguridad cuántica como una afirmación sobre una sola capa. Cuando un proveedor denomina seguro frente a la computación cuántica a un producto, describe la capa que haya indicado, y normalmente esa capa es un intercambio de claves. Solicite el nombre del algoritmo y el protocolo al que se aplica. Para OpenSSH en agosto de 2026, la formulación correcta es que el intercambio de claves es híbrido y poscuántico, mientras que las firmas son clásicas. Cualquier afirmación más amplia debe incluir un nombre que pueda encontrar en la salida de ssh -Q kex.

Siga haciendo las tareas rutinarias. Un intercambio de claves poscuántico no soluciona una contraseña fácil de adivinar ni una clave privada copiada en un portátil que después es robado. Esas son las causas reales de muchas intrusiones en servidores, y el endurecimiento estándar de SSH en un VPS sigue siendo la medida más importante. Si los pasos de negociación descritos aquí no le resultaban familiares, qué hace SSH al conectarse explica las etapas que esta página da por conocidas.

FAQ

¿Mi conexión SSH ya es poscuántica?

Ejecute ssh -v yourserver 2>&1 | grep 'kex: algorithm' y lea el nombre que muestra. mlkem768x25519-sha256 y sntrup761x25519-sha512@openssh.com son intercambios híbridos poscuánticos. curve25519-sha256, ecdh-sha2-nistp256 y cualquier nombre diffie-hellman-group son clásicos. Ambos extremos necesitan una versión que ofrezca un nombre poscuántico, porque la negociación selecciona la primera opción del cliente que también admite el servidor. Por tanto, la máquina más antigua determina el límite.

¿Qué versión de OpenSSH hizo que el intercambio de claves poscuántico fuera el predeterminado?

OpenSSH 9.0, publicada el 2022-04-08, hizo que sntrup761x25519-sha512@openssh.com fuera el intercambio de claves predeterminado. OpenSSH 9.9, publicada el 2024-09-19, añadió mlkem768x25519-sha256, y OpenSSH 10.0, publicada el 2025-04-09, hizo que esa opción fuera la predeterminada. OpenSSH 10.1, publicada el 2025-10-06, empezó a mostrar una advertencia cuando una conexión no negocia ninguna de las dos. Compruebe qué hace su propia compilación con ssh -Q kex y ssh -G <host>, porque su versión de Ubuntu determina cuáles de ellas tiene.

¿Debo generar una clave SSH poscuántica?

No, porque OpenSSH no tiene ese tipo de clave. Hasta ahora, el trabajo poscuántico cubre el intercambio de claves. Este no necesita archivos de claves ni configuración por su parte. Las claves de host y las claves de inicio de sesión siguen usando firmas clásicas, como Ed25519 y RSA. El proyecto upstream ha indicado que las firmas poscuánticas llegarán en una versión futura. Siga usando una clave Ed25519 y proteja su ubicación de almacenamiento.

¿Por qué ssh advierte de que mi conexión no es poscuántica?

OpenSSH 10.1 y las versiones posteriores muestran ** WARNING: connection is not using a post-quantum key exchange algorithm. cuando el intercambio negociado no tiene un componente poscuántico. La advertencia se refiere al servidor, no al cliente, porque su cliente ofreció un nombre poscuántico y el servidor no aceptó ninguno. Actualice OpenSSH en el servidor o compruebe que nadie haya fijado una línea KexAlgorithms en su sshd_config que excluya los nombres modernos. Establecer WarnWeakCrypto no oculta el mensaje, pero deja la conexión exactamente igual de débil.