SSH poscuántico en Ubuntu: qué cambió y qué no

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 su tráfico hoy y lo descifre dentro de varios años. La protección es real, pero más limitada 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, normalmente denominado «kex», es el primer paso de toda conexión SSH: ambos extremos acuerdan un secreto compartido y ese secreto cifra todo lo que sigue. La parte que cambió es el intercambio de claves. Nada más cambió.

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 ninguna 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 de la versión de OpenSSL. ssh -Q kex muestra un algoritmo de intercambio de claves por línea. En una compilación compatible con criptografía 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 lo que ofrece

Esta es la distinción que omiten la mayoría de los artículos. ssh -Q kex responde a una pregunta: qué podría hacer este binario. No responde a la pregunta que le interesa: 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 extremo. 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 admite un intercambio de claves poscuántico, pero ninguna conexión llega a solicitarlo.

Leer el algoritmo negociado por la conexión

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

Entre un cliente actualizado y un servidor actualizado, 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 mostrar esto:

debug1: kex: algorithm: curve25519-sha256

Ese nombre no tiene un 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 por la que se cambió el 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 elegido es el primer nombre de la lista del cliente que también aparece en la del servidor. Gana la preferencia del cliente, 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.

Conviene conocer ssh -v por más motivos que esta línea, porque esa misma salida es donde puede localizar un error Permission denied (publickey) cuando se rechaza directamente un inicio de sesión.

Quite grep y ssh -v para mostrar el resto de la negociación, incluida la línea de 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 el valor predeterminado

Las notas de la versión del proyecto muestran una secuencia clara. Las fechas son más importantes que los números de versión porque indican 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 comportamiento 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 el valor predeterminado para el acuerdo 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 opción WarnWeakCrypto de ssh_config controla esta función y está habilitada de forma predeterminada.

Hay que recordar abril de 2022. Cualquier par de máquinas que ejecute OpenSSH 9.0 o una versión posterior realiza un intercambio de claves poscuántico desde entonces, sin configuración adicional y sin avisar a la persona que escribe ssh.

Qué versión de Ubuntu lo incluye

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

• Ubuntu 22.04 LTS incluye 1:8.9p1, anterior al valor predeterminado introducido en 9.0, por lo que una instalación estándar negocia curve25519-sha256.
• Ubuntu 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.
• Ubuntu 25.10 incluye 1:10.0p1, cuyo valor predeterminado es mlkem768x25519-sha256.
• Ubuntu 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 equipos real. Un portátil con 26.04 se conecta a un servidor con 24.04. La primera opción del cliente, mlkem768x25519-sha256, no aparece en la lista del servidor 9.6. La siguiente opción poscuántica del cliente que el servidor 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 revés 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. Configurar WarnWeakCrypto no elimina el mensaje y no cambia la conexión.

Por qué el enfoque híbrido y qué significa recopilar ahora y descifrar después

La amenaza tiene una forma 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. No requiere nada sofisticado por parte del atacante en el presente. Sólo requiere espacio en disco y paciencia.

Este problema afecta al cifrado, pero no a las firmas, y esa 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 comprueba. Romper un algoritmo de firma en 2035 permitiría a alguien suplantar un servidor en 2035. No le permitiría volver atrás y falsificar un inicio de sesión de 2026. Por eso había que corregir primero el intercambio de claves, mientras que el componente de firma podía esperar.

Híbrido significa que se ejecutan ambos algoritmos y que ambos resultados se incorporan a la clave de sesión. Para recuperar el secreto protegido por 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 tenido mucho menos tiempo de análisis por parte 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 se obtuvo mediante 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 acceso a un ordenador cuántico operativo podría falsificar esa firma y suplantar el servidor, pero sólo durante una conexión activa en ese momento futuro, y 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, por lo que se aplica el mismo razonamiento. Lo que protege esa clave este año es dónde se almacena y quién puede leerla. Por eso, la gestión sensata de claves SSH reduce mucho más el riesgo real que cualquier nombre de algoritmo de esta página.

No tiene que hacer nada con respecto a ninguna de esas claves, porque todavía no hay nada a lo que cambiar. OpenSSH ha indicado que el soporte de 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 ofrece ninguno. Una guía que le indique que genere una describe software que todavía no existe.

TLS en el mismo servidor es una cuestión independiente y tiene una respuesta diferente. 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 con un calendario diferente. Actualizar OpenSSH no cambia nada en ese ámbito. Si ejecuta 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 tanto, debe analizar esa pila por separado.

Qué debe hacer ahora un operador sensato

Mantenga OpenSSH actualizado y deténgase ahí. Esa es toda la estrategia para este problema. sudo apt update && sudo apt upgrade mantiene el sistema en la versión que incluye su versión de Ubuntu, y pasar a una versión más reciente de Ubuntu es lo que actualiza OpenSSH a una versión más reciente. Activar las actualizaciones de seguridad desatendidas aplica esos parches sin que tenga que acordarse de hacerlo. Compilar OpenSSH desde el código fuente para perseguir el nombre de un algoritmo no compensa, porque se renuncia a las actualizaciones de seguridad de la distribución para el servicio más expuesto del sistema. 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. Es la única acción que empeora la situación de forma sistemática. Una guía de bastionado de 2018 le entrega una lista que era correcta en 2018, y pegarla en sshd_config reemplaza la lista predeterminada en lugar de añadir elementos. Todos los algoritmos creados desde entonces quedan excluidos, por lo que un servidor que habría negociado mlkem768x25519-sha256 por sí solo pasa silenciosamente al algoritmo que sobreviva 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 adició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 indique un algoritmo que la compilación no incluye impide que sshd se inicie, y en un equipo remoto eso significa que no podrá volver a entrar. 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 la publicidad de «quantum-safe» como una afirmación sobre una sola capa. Cuando un proveedor denomina quantum-safe a un producto, describe la capa que haya indicado, que normalmente es un intercambio de claves en algún punto. Solicite el nombre del algoritmo y el protocolo al que se aplica. Para OpenSSH en agosto de 2026, la formulación precisa es que el intercambio de claves es híbrido y poscuántico, mientras que las firmas siguen siendo clásicas. Cualquier afirmación más amplia debe incluir un nombre que pueda encontrar en la salida de ssh -Q kex.

Siga aplicando las medidas básicas. Un intercambio de claves poscuántico no resuelve una contraseña fácil de adivinar ni una clave privada copiada en un portátil que después sea robado. Esos son los factores que realmente permiten tomar el control de los servidores, y el bastionado 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 elige la primera opción del cliente que también admite el servidor. Por tanto, la máquina más antigua establece el límite.

¿Qué versión de OpenSSH convirtió el intercambio de claves poscuántico en el valor predeterminado?

OpenSSH 9.0, publicada el 2022-04-08, convirtió sntrup761x25519-sha512@openssh.com en 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, convirtió esta última en la opción 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 esas opciones 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, que no necesita archivos de clave 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 que mi conexión no es poscuántica?

OpenSSH 10.1 y 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 el OpenSSH del servidor o compruebe que nadie haya fijado una línea KexAlgorithms en su sshd_config que excluya los nombres modernos. Configurar WarnWeakCrypto no oculta el mensaje, pero deja la conexión exactamente con la misma debilidad.