SSH — el acceso remoto

Una shell sobre una red hostil

SSH (Secure Shell) resuelve un problema más amplio que TLS: no solo cifrar tráfico, sino ejecutar comandos en una máquina remota como si estuvieras delante de ella, sobre una red en la que cualquiera puede estar mirando.

El handshake SSH cubre tres asuntos, parecidos a los de TLS pero con matices propios. Acuerdo de clave: cliente y servidor establecen una clave de sesión sin que un atacante en medio pueda obtenerla — históricamente con Diffie-Hellman, hoy con curvas elípticas o ya con híbridos post-cuánticos. Autenticación del servidor: el cliente verifica la host key del servidor — si es la primera conexión, la guarda en ~/.ssh/known_hosts (el famoso "Trust On First Use"); si ya existe y no coincide, salta la alerta de man-in-the-middle que todos hemos visto alguna vez. Autenticación del cliente: típicamente con clave pública/privada — tú demuestras al servidor que tienes la clave privada cuya pública está en authorized_keys.

El atacante a derrotar es similar al de TLS — un MitM en la red — pero hay un actor adicional: el atacante que captura tráfico hoy y lo descifra mañana. Las sesiones SSH suelen contener cosas como credenciales de bases de datos, claves de cifrado, código fuente propietario — datos cuyo valor sobrevive perfectamente 10, 20 o 30 años. Justo lo que un Estado quiere guardar para Q-Day.

Estos tres asuntos no envejecen igual. El KEX ya está en pleno proceso de migración a PQC. La identidad del servidor (host key) y del usuario (user key) están mucho más atrasadas — y son problema. Veremos por qué en la sección 5.

De SSH-1 al default post-cuántico

Igual que TLS, SSH ha tenido que ir tirando algoritmos rotos por el camino. Pero a diferencia de TLS, SSH llegó antes a la era post-cuántica: dos versiones por delante en el calendario.

• 1995
  SSH-1 · Tatu Ylönen
  Primer SSH, propietario. Diseño con vulnerabilidades graves (insertion attack en CRC). Deprecado.
• 2006
  SSH-2 · RFCs 4250-4254
  Estandarizado en IETF. Reescritura completa: separación de transporte, autenticación y conexión. Es el SSH que usas hoy.
• 2014
  OpenSSH 6.5 · Ed25519 + curve25519
  Soporte de claves Ed25519 y curve25519-sha256 para KEX. Empieza el alejamiento de las curvas NIST.
• 2021
  OpenSSH 8.8 · ssh-rsa (SHA-1) deshabilitado
  Por defecto se elimina la firma RSA con SHA-1, considerada criptográficamente rota. Causa breakage en muchos sistemas legacy.
• 2022
  OpenSSH 9.0 · sntrup761x25519 default
  Primera versión con KEX post-cuántico híbrido por defecto: sntrup761x25519-sha512. Streamlined NTRU Prime + X25519.
• 2024
  OpenSSH 9.9 · ML-KEM disponible
  Se añade mlkem768x25519-sha256, basado ya en el ML-KEM estandarizado por NIST en FIPS 203.
• Abril 2025
  OpenSSH 10.0 · ML-KEM como default
  mlkem768x25519-sha256 pasa a ser el KEX por defecto. SSH se convierte en uno de los primeros protocolos masivos con PQC standard estandarizado en producción.
• Sep 2025
  GitHub habilita PQC SSH
  GitHub.com pasa a ofrecer sntrup761x25519-sha512 en sus endpoints SSH para Git. Cualquier git push moderno ya pasa por PQC.
• 2026 →
  OpenSSH 10.1 · warning automático
  El cliente avisa explícitamente al usuario cuando el servidor no ofrece KEX post-cuántico. Si has visto el mensaje "store now, decrypt later" al conectarte a un servidor viejo, ya sabes de dónde viene.

Lo que hoy se considera "bien hecho"

Sin entrar todavía en post-cuántica, esta es la línea base de un SSH bien configurado en 2026.

Esto define el "bien hecho" clásico. La trampa es que SSH es tan compatible hacia atrás que muchos servidores siguen ofreciendo algoritmos legacy "por si acaso". Y aquí viene la era cuántica.

Tres asuntos, tres veredictos distintos

Aquí SSH se parte en tres frentes con destinos cuánticos muy diferentes. La parte simétrica está bien; el KEX ya migró; la autenticación todavía está en RSA/ECDSA y eso es un problema.

Hay un matiz que conviene resaltar y que el público suele pasar por alto: Ed25519 también cae. Ser una curva moderna, segura y bien diseñada no le sirve de nada frente a Shor. Cualquier criptografía basada en logaritmo discreto — sea sobre enteros, curvas NIST o curvas de Edwards — se rompe.

Tus host keys son el archivo más comprometedor de tu infraestructura. Llevan años sin rotarse, son Ed25519 o RSA, y un atacante con ordenador cuántico puede falsificarlas el día Q.

Y al revés que con TLS — donde los certificados expiran cada 90 días con Let's Encrypt — las claves SSH no caducan solas. Es completamente normal encontrar host keys generadas en 2018 y nunca rotadas. Esa es exactamente la superficie de ataque que un atacante quiere preservar: si captura el handshake hoy y guarda la host key pública, en el día Q la firma falsificada con la privada "recuperada" cuántica le permite impersonar el servidor para siempre — porque nadie mira el fingerprint de un servidor que llevan 8 años usando.

El KEX ya migró. La autenticación, no.

SSH ha hecho el primer movimiento rapidísimo comparado con otros protocolos: ML-KEM ya es el default en OpenSSH 10.0. Pero el resto del cuadro está mucho más vacío de lo que parece.

Estado real por frente

Esta asimetría es importante: el KEX cuántico-seguro no salva tu autenticación. Si el día Q el atacante puede falsificar la host key, da igual que la clave de sesión esté protegida con ML-KEM — te puede redirigir a un servidor falso desde cero.

El warning de OpenSSH 10.1

Desde OpenSSH 10.1 el cliente muestra automáticamente este aviso cuando se conecta a un servidor que no ofrece KEX post-cuántico:

Si ves esto en tus logs, tienes deuda criptográfica medible: o el servidor es viejo, o tiene los algoritmos PQC deshabilitados explícitamente. Es un test gratis del nivel de madurez de cualquier proveedor con el que conectes — y un argumento técnico irrebatible para forzar upgrades.

Los 6 criterios de la auditoría

Igual que en TLS, estos serán los criterios del examen final para SSH. La diferencia es que aquí el techo de PQC es más bajo — ML-KEM en KEX existe, pero PQC en firmas todavía no es producción. El nivel Q-Day Proof requiere híbrido en KEX y piloto de firmas PQC.

Mapeo a badge: 0–30 Classical · 31–55 Hybrid-Ready · 56–75 Quantum-Safe · 76–90 Q-Day Proof. La paradoja de SSH es que hoy es relativamente fácil llegar a Quantum-Safe (basta con OpenSSH 10.0 + buena config), pero imposible llegar a Q-Day Proof completo sin entrar en territorio experimental con firmas PQC.