Por Canuto  

OpenSSH 10.4 ya está disponible y llega con una mezcla relevante de parches de seguridad, cambios potencialmente incompatibles y una novedad que mira al futuro de la criptografía: soporte experimental para firmas compuestas postcuánticas. La actualización corrige problemas en sftp, scp, sshd y ssh, además de endurecer el protocolo ante comportamientos maliciosos durante el reintercambio de claves.
***

  • OpenSSH 10.4 fue lanzado el 6 de julio de 2026 con varias correcciones de seguridad y cambios de endurecimiento del protocolo.
  • La versión agrega soporte experimental para firmas compuestas postcuánticas basadas en ML-DSA 44 y Ed25519.
  • También introduce cambios potencialmente incompatibles en sshd y en sistemas Linux con sandbox seccomp habilitado.

OpenSSH 10.4 fue lanzado el 6 de julio de 2026 y ya está disponible a través de los espejos listados en el sitio oficial del proyecto. La actualización incluye correcciones de seguridad, ajustes generales de errores y un pequeño conjunto de nuevas funciones.

Para administradores de sistemas, empresas y desarrolladores, OpenSSH es una pieza esencial de la infraestructura moderna. Se trata de una implementación completa del protocolo SSH 2.0 y también incorpora soporte para clientes y servidores SFTP.

La nueva edición no solo corrige fallas concretas en herramientas como sftp(1), scp(1), sshd(8) y ssh(1). También endurece el comportamiento del transporte SSH frente a escenarios donde un par malicioso intenta abusar del intercambio de claves para consumir memoria o alterar flujos esperados.

Ese tipo de cambios suele pasar desapercibido para el usuario común, pero tiene peso operativo real en centros de datos, nubes, universidades y redes corporativas. SSH sigue siendo una de las bases del acceso remoto seguro, por lo que incluso ajustes pequeños pueden afectar políticas, automatizaciones y despliegues.

El anuncio también agradece a la comunidad de OpenSSH por su apoyo continuo, especialmente a quienes aportaron código, parches, reportes de errores, pruebas preliminares o donaciones. El proyecto mantiene además información pública para quienes deseen contribuir financieramente a su desarrollo.

Cambios potencialmente incompatibles y endurecimiento del protocolo

Uno de los cambios potencialmente incompatibles afecta a sshd(8) en su modo de volcado de configuración. A partir de OpenSSH 10.4, el comando “sshd -G” ahora emite las directivas respetando mayúsculas y minúsculas, como “PubkeyAuthentication”, en lugar de escribir únicamente nombres en minúsculas.

Ese detalle puede parecer menor, pero puede impactar scripts, herramientas de auditoría o procesos automatizados que comparan salidas de configuración de manera exacta. En entornos productivos, este tipo de variación suele requerir pruebas antes de desplegar masivamente.

Otro cambio importante se aplica a sistemas Linux con sandbox seccomp habilitado. Según explicó OpenSSH en su nota de lanzamiento, los fallos al activar SECCOMP o NO_NEW_PRIVS ahora son fatales para sshd(8), cuando antes solo se registraban en logs y el servicio seguía funcionando.

La implicación práctica es clara para sistemas antiguos o entornos con capacidades limitadas. Si la plataforma no ofrece esas características, ahora será necesario deshabilitar el sandbox en tiempo de configuración para evitar fallos de operación.

La versión 10.4 también vuelve más estricto el protocolo de transporte en ssh(1) y sshd(8). Si el par envía mensajes que no pertenecen a KEX durante un reintercambio de claves posterior a la autenticación, la conexión será desconectada.

Antes, un par malicioso podía seguir enviando mensajes no vinculados al intercambio de claves sin sufrir penalización inmediata. Esos mensajes quedaban en búfer y podían desperdiciar memoria hasta el cierre de la conexión o hasta que el cliente o servidor alcanzara un límite de memoria.

OpenSSH advirtió además que implementaciones que no restrinjan los mensajes enviados durante el intercambio de claves conforme a la sección 7.1 del RFC4253 podrían ser desconectadas. El problema fue reportado por Marko Jevtic.

Fallas de seguridad corregidas en sftp, scp y sshd

Entre las correcciones de seguridad más relevantes, OpenSSH 10.4 repara un problema en sftp(1). Al descargar archivos desde la línea de comandos con una instrucción como “sftp host:/path .”, un servidor malicioso podía lograr que el archivo terminara en una ubicación inesperada.

Ese hallazgo fue identificado por el Escáner de Seguridad Swival. En escenarios corporativos, un comportamiento así puede alterar flujos automatizados de descarga o generar confusión sobre la integridad del destino elegido por el operador.

La nueva versión también corrige una falla en scp(1) al copiar archivos entre dos destinos remotos. En ese caso, un servidor malicioso ya no podrá escribir archivos en el directorio padre del directorio de destino previsto.

Ese problema también fue detectado por el Escáner de Seguridad Swival. Aunque el vector depende de un servidor remoto malicioso, la corrección resulta relevante para operaciones de copia entre hosts bajo automatización o administración distribuida.

En sshd(8), se resolvió un problema ligado al uso del servidor SFTP “internal-sftp”, que no es la configuración predeterminada. Las líneas de comando largas eran truncadas silenciosamente después del noveno argumento.

La consecuencia de ese truncamiento era delicada. Si una opción relevante para la seguridad aparecía en la décima posición o una posterior, quedaba descartada sin aviso, lo que podía alterar el comportamiento esperado del servicio.

Ese caso fue reportado por Steve Caffrey. OpenSSH también añadió una nota en la documentación para aclarar que la opción GSSAPIStrictAcceptorCheck no es efectiva cuando el servidor está unido a un Active Directory de Windows.

Ese detalle documental fue señalado por Yarin Aharoni, de Safebreach. Aunque no se trata de una nueva vulnerabilidad en sí misma, la aclaración reduce riesgos de interpretación errónea en organizaciones que dependen de GSSAPI junto con infraestructura de Microsoft.

La versión 10.4 además corrige un incumplimiento entre documentación y comportamiento real en sshd(8). DisableForwarding=yes no estaba sobrescribiendo PermitTunnel=yes como debía hacerlo, aunque OpenSSH recuerda que PermitTunnel no viene activado por defecto.

Ese problema fue reportado de forma independiente por Huzaifa Sidhpurwala, de Redhat, y por Marko Jevtic. También se mitigó una posible denegación de servicio previa a la autenticación cuando GSSAPIAuthentication estaba habilitado, una función desactivada por defecto.

Según el proyecto, ese escenario no era mitigado por MaxAuthTries, aunque sí quedaba penalizado por PerSourcePenalties. El reporte fue realizado por Manfred Kaiser, de milCERT AT, dependiente del Ministerio de Defensa de Austria.

OpenSSH 10.4 también corrige varios casos en los que no se aplicaba el retraso mínimo de autenticación. Esa observación fue presentada por el Equipo de Vulnerabilidad de Orange Cyberdefense.

Del lado del cliente, ssh(1) recibió un arreglo para un posible uso después de liberar memoria si el servidor cambiaba su clave host durante un reintercambio de claves. Ese problema fue reportado por Zhenpeng, conocido como Leo Lin, de Depthfirst.

Soporte experimental postcuántico y otras mejoras técnicas

La novedad más llamativa de esta versión es la incorporación de soporte experimental para un esquema de firma compuesto postcuántico. OpenSSH combina ML-DSA 44 y Ed25519 según lo especificado en draft-miller-sshm-mldsa44-ed25519-composite-sigs.

El término postcuántico describe herramientas criptográficas diseñadas para resistir escenarios futuros en los que computadoras cuánticas puedan romper o debilitar esquemas hoy considerados seguros. Aunque ese horizonte todavía genera debate sobre tiempos y riesgos concretos, la preparación temprana ya forma parte de la agenda de seguridad en múltiples industrias.

OpenSSH aclaró que este esquema no viene habilitado por defecto. Quien quiera usarlo deberá agregarlo manualmente a parámetros como HostKeyAlgorithms y PubkeyAcceptedAlgorithms, entre otros.

Las claves pueden generarse mediante el comando “ssh-keygen -t mldsa44-ed25519”. El hecho de que la función sea experimental sugiere un enfoque prudente, pensado más para evaluación, pruebas y maduración técnica que para adopción inmediata a gran escala.

Otra mejora importante en ssh(1) y sshd(8) es el reemplazo del patrón de coincidencia de comodín por una implementación basada en un NFA. Ese cambio evita el comportamiento exponencial en el peor de los casos que estaba presente en la implementación anterior.

Más allá de esta novedad, la lista de correcciones técnicas es extensa. ssh-agent(1) arregla una respuesta incorrecta a solicitudes SSH_AGENTC_EXTENSION “query”, mientras ssh(1) y sshd(8) corrigen errores que clasificaban tráfico masivo como si fuera interactivo.

OpenSSH 10.4 también omite tipos de clave no soportados al descargar claves residenciales desde un token FIDO con ssh-keygen(1) y ssh-add(1). Antes, la descarga se abortaba al encontrar uno de esos tipos no admitidos.

En sftp(1) se corrigieron dos lecturas fuera de límites de un byte, una en SSH2_FXP_REALPATH y otra en el procesamiento de comandos por lotes. Además, sftp-server(8) ahora prohíbe usar la extensión copy-data para leer y escribir en el mismo inode simultáneamente.

La versión también corrige un fallo en strlen(NULL) que podía activarse si se creaba un canal X11 antes de enviar el mensaje x11-req de tipo SSH_MSG_CHANNEL_REQUEST. Además, sftp(1) y scp(1) evitan quedar atrapados en un bucle si un servidor defectuoso devolvía repetidamente longitud cero al leer un archivo.

Entre otros ajustes, ssh(1) evita filtrar nombres aleatorios DNS0x20 en nombres canonizados mediante CanonicalizePermittedCNAMEs. También se corrige la construcción de máscaras de eventos poll(2) para algunos canales de tipo socket.

Refactorización, portabilidad y verificación para administradores

OpenSSH 10.4 incluye una refactorización importante del análisis y manejo de sshd_config. El objetivo es permitir una serialización y deserialización más precisa a través de los límites de separación de privilegios.

Ese cambio acompaña otra medida de endurecimiento en sshd(8), que ahora realiza una codificación y validación más estrictas del estado de transporte transmitido entre subprocesos con separación de privilegios. Según el proyecto, esto robustece un poco más el servidor frente a ataques sobre sshd-auth o sshd-session.

La actualización también toca componentes criptográficos internos. Se corrige una verificación de límites al firmar mensajes cuya longitud excedería lo que cabe en un size_t, aunque OpenSSH señaló que este límite no era alcanzable porque los mensajes están restringidos por SSHBUF_SIZE_MAX.

El código de cifrado suma además verificaciones de maleabilidad de firma y validez de clave pública para Ed25519. OpenSSH indicó que SSH no depende de esas propiedades, pero el refuerzo añade defensa adicional a la validación criptográfica.

También se corrige la verificación del orden de ECDSA para curvas con cofactor distinto de 1. Sin embargo, el proyecto remarcó que todas las curvas EC soportadas tienen cofactor 1, por lo que ese caso tampoco era alcanzable en la práctica habitual.

En portabilidad, la versión sincroniza fmt_scaled.c y getrrsetbyname.c con el upstream de OpenBSD para incorporar mejoras de exactitud y robustez. Además, elimina una entrada de sandbox duplicada para clock_gettime64 y revisa README.privsep para reflejar el modelo reciente de sshd como sistema multi-binary.

La edición 10.4 también ajusta el valor correcto de IPTOS_DSCP_VA cuando los encabezados del sistema no lo proveen. A esto se suman correcciones de fugas de memoria en rutas de error del código de portabilidad y la desactivación de reemplazos openbsd-compat para strvisx(3) y stravis(3), ya que OpenSSH no los utiliza.

Para administradores y equipos de seguridad, el mensaje de fondo es doble. Primero, la versión resuelve fallas concretas que afectan rutas de autenticación, transferencia de archivos y robustez del servicio; segundo, introduce cambios de comportamiento que conviene probar con cuidado antes de desplegarlos en ambientes críticos.

El proyecto publicó además las sumas de verificación SHA1 y SHA256 para openssh-10.4.tar.gz y openssh-10.4p1.tar.gz, y recordó que las firmas SHA256 están codificadas en base64, no en hexadecimal. La clave PGP usada para firmar los lanzamientos está disponible en los sitios espejo oficiales.

Para reportar errores, OpenSSH pide revisar su guía pública de reporte. Los fallos de seguridad deben informarse directamente al correo openssh@openssh.com.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados