Más allá de la etiqueta de versión, OpenSSH 10.1 consolida el rumbo iniciado con la serie 10: migración hacia criptografía post‑cuántica, modernización de QoS con DSCP, y endurecimiento de áreas históricamente sensibles (agentes, claves, registros y parsing de parámetros). A continuación encontrarás un repaso minucioso de todas las novedades (con contexto donde aporta valor), además de pautas prácticas para adoptarlas sin sorpresas.
Lo que sigue es la lista con las novedades de esta versión, disponibles también en las notas oficiales.
Novedades destacadas y contexto de la versión
La publicación oficial de OpenSSH 10.1 (2025‑10‑06) subraya tres ejes: seguridad preventiva frente a criptografía cuántica, redes con DSCP y saneamiento de entradas. Conecta además cambios puntuales de gran impacto operativo: desde rutas de sockets del agente hasta nuevas señales de diagnóstico.
Un recordatorio clave del proyecto: una futura versión ignorará los registros SSHFP basados en SHA‑1, mientras que ssh-keygen -r ya genera huellas SSHFP solo con SHA‑256 por defecto, cerrando la puerta a hash débiles de cara a DNSSEC y verificación de host keys.
Aviso por criptografía no post‑cuántica y nueva opción WarnWeakCrypto
OpenSSH 10.1 introduce un aviso cuando la conexión negocia un intercambio de claves que no es resistente a ataques post‑cuánticos. El objetivo es poner foco en el riesgo de ‘store now, decrypt later’ (almacenar ahora, descifrar después) y acelerar la transición en entornos sensibles.
Este comportamiento se controla con WarnWeakCrypto (en ssh_config), que viene activado por defecto. Si estás en una migración gradual o mantienes hosts legacy, puedes desactivar el aviso de forma selectiva con bloques Match. Por ejemplo:
Match host unsafe.example.com
WarnWeakCrypto no
Criptografía y estado del arte: PQC, híbridos y SSHFP
En 10.0, el cliente pasó a usar por defecto mlkem768x25519‑sha256, un algoritmo híbrido post‑cuántico que combina ML‑KEM (KEM NIST FIPS 203) con X25519. Esta estrategia híbrida garantiza que, incluso si surgiera un avance criptoanalítico en la parte PQ, no estarías peor que con ECDH clásico porque el canal conserva la fuerza de X25519.
Con 10.1, además del aviso explicado antes, se refuerza la transición: OpenSSH seguirá ignorando en el futuro SSHFP con SHA‑1; la herramienta ssh-keygen ya emite SSHFP con SHA‑256 exclusivamente. En términos operativos, la acción recomendada es regenerar y publicar huellas SSHFP en SHA‑256 para tus hosts.
Preguntas habituales: ¿por qué insistir ahora si los ordenadores cuánticos aún no pueden romper SSH? Porque los atacantes pueden capturar hoy y descifrar mañana. Usar KEX post‑cuántico ya mitiga ese vector. Y si te inquieta la juventud de los algoritmos PQ, recuerda que la modalidad híbrida mantiene el nivel de seguridad clásico como base.
Modernización de red: DSCP/IPQoS y priorización de tráfico
Esta versión consolida una revisión profunda de QoS. En cliente y servidor, el tráfico interactivo adopta por defecto la clase EF (Expedited Forwarding), lo que ayuda a reducir latencias en Wi‑Fi y medios congestionados. El tráfico no interactivo pasa a usar la marca DSCP por defecto del sistema, sin elevar prioridad.
En la práctica, tanto ssh(1) como sshd(8) cambian dinámicamente la marca empleada según el tipo de canales presentes: si una misma conexión combina un shell y un sftp, la fase de transferencia no interactiva usará el valor no interactivo durante la operación y volverá a EF cuando corresponda. Esto se controla mediante la clave IPQoS en ssh_config y sshd_config.
Además, se retira el soporte de los antiguos ToS de IPv4 en la opción IPQoS (lowdelay, throughput, reliability dejan de tener efecto). Si aún los usabas, migra a nomenclatura DSCP (p. ej., ef, cs0, af11, etc.).
Endurecimiento de entradas: usuarios, URIs y expansiones
En el apartado de seguridad, 10.1 corrige un caso sutil donde, si construías líneas de comando con datos externos y a la vez usabas ProxyCommand con expansiones tipo %r/%u, un atacante podía colar expresiones de shell. Para mitigarlo, ssh(1) ahora prohíbe caracteres de control en usuarios pasados por CLI o expandidos, y también bloquea el carácter nulo en URIs ssh://.
Nota de compatibilidad: se ha relajado un punto de validación para no romper casos legítimos. Los nombres de usuario literales definidos en archivos de configuración (sin expansiones %) quedan exentos, sobre la base de que el config local se considera de confianza.
Señales e información en vivo: SIGINFO y visibilidad
Otro avance práctico para depuración: ssh(1) y sshd(8) ganan manejadores SIGINFO que registran el estado de canales y sesiones activas. En producción, esto facilita diagnósticos de flujos, multiplexación, reenvíos y X11 sin necesidad de adjuntar un depurador o elevar verbosidad de forma invasiva.
En la misma línea de transparencia, cuando una autenticación con certificado falla, sshd ahora registra información suficiente para identificar el certificado (además de por qué se ha denegado). Si trabajas con PKI y certificados de usuario/host, esta mejora acorta muchísimo los tiempos de resolución.
ssh‑agent y claves: sockets, limpieza y PKCS#11
Para evitar accesos cruzados en entornos con montaje restringido de /tmp, los sockets del agente (y los reenviados por sshd) se mueven de /tmp a ~/.ssh/agent. Así, un proceso con permisos limitados sobre /tmp ya no hereda por accidente la posibilidad de firmar con tus claves del agente.
Este cambio tiene otra derivada: antes el SO podía limpiar sockets obsoletos, ahora ssh‑agent incorpora su propia limpieza de sockets antiguos. Además, el agente suma nuevas banderas: -U y -u para controlar limpieza al arrancar, -uu para ignorar hostname en limpieza, y -T para forzar la ubicación histórica en /tmp si de verdad la necesitas.
En el plano de claves, el cliente y el agente ya soportan ed25519 alojadas en tokens PKCS#11. Si dependes de HSM o llaves criptográficas, ganarás flexibilidad sin ceder fortaleza.
ssh‑add y certificados: caducidad auto‑limpiable
Cuando añades certificados al agente, ahora se fija su expiración con una gracia de 5 minutos. La idea es simple: permitir finalizar transacciones en cola y, acto seguido, eliminar el certificado del agente de forma automática. Si tu flujo exige control total, ssh‑add -N desactiva este comportamiento.
RefuseConnection: cortes controlados desde el lado cliente
Hay escenarios donde te interesa abortar una conexión desde el propio cliente con un mensaje claro (por ejemplo, redirecciones operativas o avisos de deprecación). OpenSSH 10.1 añade RefuseConnection a ssh_config: si se encuentra mientras se procesa una sección activa, el cliente termina con error y muestra el texto que hayas definido.
Calidad del código y seguridad viva
El equipo continúa con el saneamiento del código base. En 10.1 se listan fugas de memoria atajadas, mejoras de atomía al escribir known_hosts a alta concurrencia y varias condiciones de carrera resueltas en procesos como MaxStartups o sesiones X11.
Un apunte de limpieza cripto: se elimina el soporte para XMSS (experimental y nunca por defecto). Preparando el terreno para esquemas de firma post‑cuánticos más maduros que llegarán en futuras versiones.
Portabilidad y ecosistema: PAM, FreeBSD, macOS, Android…
Los cambios de portabilidad tocan muchos frentes: comprobaciones extra en entornos PAM (como asegurar que el usuario no cambia durante el proceso), mejoras de integración con FreeBSD (tun forwarding y compatibilidad), macOS (detección robusta de funciones y headers) y Android (struct passwd con campos no nulos).
También se añaden cabeceras de compatibilidad para plataformas sin ciertas bibliotecas estándar, reduciendo el número de #ifdef dispersos. Por último, se afinan políticas de sandbox seccomp en Linux para cubrir syscalls como futex_time64 en 32‑bit, y se suma soporte a AWS‑LC como alternativa a OpenSSL/LibreSSL.
QoS en acción: ejemplos prácticos y migración de IPQoS
Si usabas los antiguos alias ToS (lowdelay, throughput…), ahora serán ignorados y verás un mensaje de depuración sugiriendo DSCP. La migración típica sería pasar de IPQoS lowdelay a IPQoS ef para sesiones interactivas; si además haces SFTP pesado, podrías definir perfiles por Match en ssh_config/sshd_config para separar tráfico.
Recuerda que el motor selecciona y actualiza automáticamente la marca en tiempo real según los canales abiertos, de modo que la mayor parte del trabajo ya lo hace OpenSSH por ti.
Instalación de OpenSSH 10.1 en Linux (fuente)
Mientras las distribuciones integran la versión, puedes compilar desde la fuente oficial. Descarga el tarball desde los mirrors del proyecto, descomprime y compila:
tar -xvf openssh-10.1.tar.gz
Entra al directorio y configura prefijos y rutas de configuración si lo necesitas. Por ejemplo:
cd openssh-10.1
./configure --prefix=/opt --sysconfdir=/etc/ssh
Compila e instala como de costumbre (según permisos, quizá con superusuario):
make install
Habilitar OpenSSH en Windows con PowerShell
En entornos Windows modernos (Server 2019/Windows 10 1809+), puedes instalar el cliente y servidor OpenSSH como características del sistema. Comprueba capacidades y estado:
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
Instala los componentes según necesites:
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Arranca y habilita el servicio del servidor SSH, y verifica la regla de firewall de entrada:
Start-Service sshd
Set-Service -Name sshd -StartupType 'Automatic'
Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -ErrorAction SilentlyContinue
Para conectarte desde otro host Windows o Linux, usa el cliente estándar: ssh dominio\usuario@servidor. En el primer acceso, acepta la huella del host y autentícate con tu password o clave.
Guía operativa: diagnósticos y buenas prácticas
Para entornos con certificados de usuario/host, aprovecha el logging mejorado de denegaciones en sshd para depurar CA y extensiones. Si una sesión se atasca o sospechas de multiplexación, lanza SIGINFO al proceso para listar canales activos sin subir el nivel global de logs.
Si dependes de agentes, revisa dónde viven los sockets ahora (~/.ssh/agent) y activa limpieza automática en tu modelo de despliegue. En estaciones compartidas o NFS, considera la bandera del agente para establecer hash de hostname en la ruta cuando haga falta.
Errores corregidos más relevantes
En 10.1 se solucionan regresiones menores en X11 cuando se combinaba con mitigaciones de pulsaciones (ObscureKeystrokeTiming), un caso de mala contabilidad de MaxStartups que podía anegar slots, y la escritura de known_hosts ahora se hace en operaciones atómicas para evitar líneas intercaladas con alta concurrencia.
Otros fixes mejoran diagnósticos al cargar claves, el tratamiento de límites de tamaño de config (de 256KB a 4MB), la salida de auditoría y corner cases exóticos en reenvíos locales y secuencias de control. Además, se ponen al día mensajes y salidas de ssh -G y sshd -T.
Checklist de migración recomendada
Esta lista rápida recoge las tareas que el propio proyecto sugiere y lo que se desprende de los cambios:
- Cripto: verifica que tu
KexAlgorithms permite híbridos PQ y genera nuevas SSHFP en SHA‑256 con ssh-keygen -r.
- QoS: revisa
IPQoS en cliente/servidor; migra ToS legacy a DSCP; aprovecha EF para sesiones interactivas.
- Agentes: adapta scripts y variables a sockets bajo
~/.ssh/agent; valora limpieza automática del propio agente.
- Configs grandes: si generas configs masivas, el límite sube a 4MB; aplícalo con cabeza y controla la validación.
- Parsers: evita construir líneas de comando desde inputs no confiables; usa
config locales con literales cuando tengas casos extraños en usernames.
Quien administre flotas mixtas agradecerá que 10.1 apriete la seguridad donde duele menos (parsers, agentes, advertencias) y a la vez mejore la experiencia diaria (QoS dinámica, SIGINFO, logging de certificados). Si ya estabas en 10.0, la transición es sencilla; si vienes de 9.x, reserva tiempo para ajustar DSCP, regenerar SSHFP en SHA‑256 y activar KEX híbridos para blindarte frente a la amenaza cuántica sin sacrificar rendimiento.
