OpenSSH 10.4 ya está disponible como una actualización centrada en seguridad, robustez del protocolo y corrección de errores en componentes utilizados diariamente para administrar servidores Linux, transferir archivos y establecer túneles cifrados.
La versión fue publicada oficialmente el 6 de julio de 2026 e incluye cambios relacionados con SFTP, SCP, autenticación GSSAPI, reintercambio de claves, separación de privilegios y validación de configuraciones. También incorpora soporte experimental para un nuevo esquema de firma poscuántica combinado con Ed25519.
Lo más importante: OpenSSH 10.4 corrige problemas que podían permitir escrituras de archivos en ubicaciones inesperadas, denegación de servicio, omisión de determinadas restricciones y fallos de memoria en el cliente SSH.
¿Qué es OpenSSH y por qué esta actualización importa?
OpenSSH es una implementación abierta del protocolo SSH utilizada para acceso remoto, ejecución de comandos, transferencia de archivos y creación de túneles cifrados.
La suite incluye herramientas conocidas como:
| Herramienta | Función principal |
|---|---|
| ssh | Conexión remota cifrada y ejecución de comandos. |
| sshd | Servicio que recibe las conexiones SSH. |
| sftp | Transferencia segura y administración remota de archivos. |
| scp | Copia de archivos entre sistemas mediante SSH. |
| ssh-keygen | Creación y administración de claves criptográficas. |
| ssh-agent | Almacenamiento temporal y uso controlado de claves privadas. |
Debido a que OpenSSH protege el acceso administrativo a servidores, cualquier fallo en su cliente, servidor o herramientas de transferencia puede afectar infraestructuras críticas, servicios cloud, plataformas DevOps y sistemas empresariales.
Principales correcciones de seguridad de OpenSSH 10.4
1. SFTP podía guardar archivos en una ubicación inesperada
Al descargar un archivo desde la línea de comandos con una expresión similar a sftp servidor:/ruta ., un servidor malicioso podía influir para que el archivo terminara en una ubicación distinta de la esperada.
Esto era especialmente relevante cuando el usuario se conectaba a un servidor no confiable o comprometido. OpenSSH 10.4 endurece el tratamiento de la ruta de destino para impedir este comportamiento.
2. SCP restringe mejor las copias entre servidores remotos
Cuando se utilizaba SCP para copiar archivos entre dos destinos remotos, un servidor malicioso podía intentar escribir en el directorio superior al destino previsto.
La nueva versión incorpora controles que impiden que el servidor salga del directorio objetivo durante este tipo de operación.
Riesgo práctico: las correcciones de SFTP y SCP protegen al usuario frente a servidores remotos manipulados. No todos los riesgos SSH proceden del cliente que inicia la conexión; el servidor remoto también puede actuar de manera maliciosa.
3. Opciones de internal-sftp podían ser ignoradas
En configuraciones que utilizaban internal-sftp, las líneas de comandos largas podían truncarse silenciosamente después del noveno argumento.
Si una opción de seguridad aparecía en la décima posición o después, podía descartarse sin que el administrador lo advirtiera. OpenSSH 10.4 corrige este comportamiento.
El problema no afectaba a todas las instalaciones, ya que internal-sftp no es el servidor SFTP predeterminado en todos los entornos. Sin embargo, es habitual utilizarlo en servidores restringidos, cuentas de intercambio de archivos y configuraciones chroot.
4. DisableForwarding ahora prevalece sobre PermitTunnel
La directiva DisableForwarding=yes no anulaba correctamente PermitTunnel=yes, pese a que la documentación indicaba que debía bloquear todas las formas de reenvío.
La corrección es relevante para servidores donde determinadas cuentas solo deben acceder a un servicio específico y no crear túneles o canales adicionales.
5. Corrección de una posible denegación de servicio con GSSAPI
El servidor SSH podía quedar expuesto a una posible denegación de servicio previa a la autenticación cuando GSSAPIAuthentication estaba habilitado.
La función permanece desactivada de forma predeterminada, pero puede encontrarse activa en empresas que integran Linux con Kerberos o Active Directory.
6. Se refuerza el retraso mínimo de autenticación
OpenSSH utiliza retrasos mínimos en determinadas respuestas de autenticación para evitar que diferencias de tiempo revelen información útil sobre usuarios válidos o métodos de acceso.
La versión 10.4 corrige varios casos donde ese retraso no se aplicaba correctamente.
7. Corrección de use-after-free en el cliente SSH
El cliente podía sufrir un posible uso de memoria después de haber sido liberada si un servidor cambiaba su clave de host durante un reintercambio de claves.
El fallo se encontraba en el cliente, por lo que el riesgo principal aparecía al conectarse a un servidor remoto malicioso o comprometido.
Protocolo más estricto durante el reintercambio de claves
Las conexiones SSH de larga duración pueden realizar un nuevo intercambio de claves para renovar el material criptográfico utilizado por la sesión.
OpenSSH 10.4 desconecta ahora al sistema remoto si este envía mensajes ajenos al intercambio de claves durante esa fase. Anteriormente, esos mensajes podían acumularse en memoria hasta que la sesión terminara o se alcanzara un límite.
El cambio reduce el riesgo de consumo innecesario de memoria y obliga a que otras implementaciones respeten con mayor precisión el comportamiento definido por el protocolo SSH.
Posible incompatibilidad: clientes o servidores SSH antiguos que envíen mensajes no permitidos durante el intercambio de claves podrían ser desconectados por OpenSSH 10.4.
Fallos de seccomp serán fatales en Linux
En sistemas Linux compilados con el sandbox seccomp, OpenSSH 10.4 ya no continúa ejecutando sshd cuando falla la activación de SECCOMP o NO_NEW_PRIVS.
Anteriormente, el servidor registraba el error, pero seguía funcionando. La nueva política adopta un enfoque de fallo seguro: si el aislamiento esperado no puede activarse, el servicio no continúa como si estuviera correctamente protegido.
Este cambio podría afectar sistemas antiguos, contenedores con restricciones especiales o kernels modificados que no proporcionen las funciones necesarias.
Firmas poscuánticas experimentales
OpenSSH 10.4 incorpora soporte experimental para un esquema de firma compuesto que combina ML-DSA-44 y Ed25519.
El objetivo es combinar una firma diseñada para resistir futuros ataques cuánticos con un algoritmo clásico ampliamente utilizado. La función no se activa de forma predeterminada y debe habilitarse expresamente en las listas de algoritmos aceptados.
Las nuevas claves pueden generarse con:
Recomendación empresarial: no sustituyas inmediatamente todas las claves actuales. Prueba el nuevo esquema en un laboratorio y verifica compatibilidad con clientes, servidores, dispositivos de red, herramientas de automatización y sistemas de respaldo.
Otras mejoras relevantes
| Componente | Mejora incluida |
|---|---|
| Patrones wildcard | Nuevo motor basado en NFA para evitar comportamientos exponenciales en casos extremos. |
| Separación de privilegios | Validación más estricta del estado transferido entre procesos de sshd. |
| FIDO | Se omiten tipos de clave no compatibles al descargar credenciales residentes. |
| SFTP | Corrección de lecturas fuera de límites, bucles y problemas con rutas. |
| Configuración | Rechazo más estricto de listas de cifrados o MAC inválidas. |
| Ed25519 y ECDSA | Validaciones criptográficas adicionales y comprobaciones de claves públicas. |
Cómo comprobar la versión instalada
Para consultar la versión del cliente SSH:
Para comprobar el paquete instalado en Ubuntu o Debian:
En Fedora, AlmaLinux, Rocky Linux o Red Hat:
Cómo actualizar OpenSSH de forma segura
No es recomendable compilar OpenSSH 10.4 manualmente sobre un servidor de producción únicamente para obtener el número de versión más reciente. Las distribuciones Linux suelen integrar y probar sus propios paquetes, además de trasladar correcciones de seguridad a versiones anteriores.
Ubuntu, Debian y Linux Mint
Fedora, Rocky Linux, AlmaLinux y Red Hat
Arch Linux y distribuciones derivadas
La disponibilidad exacta de OpenSSH 10.4 dependerá del calendario de cada distribución. Un sistema puede estar protegido mediante parches trasladados por el proveedor aunque todavía muestre una versión anterior.
Validar la configuración antes de recargar SSH
Antes de reiniciar o recargar el servicio, comprueba que el archivo de configuración no contenga errores:
Si el comando no muestra errores, recarga el servicio. En Ubuntu y Debian suele utilizarse:
En Fedora, RHEL, Rocky Linux o AlmaLinux:
Precaución: mantén una sesión SSH abierta mientras pruebas una nueva conexión desde otra terminal. Así podrás corregir la configuración si el nuevo acceso falla.
Qué debería revisar una empresa antes de actualizar
- Inventariar servidores, clientes, appliances y herramientas que utilizan SSH.
- Probar compatibilidad con clientes antiguos y equipos de red.
- Revisar configuraciones de internal-sftp, GSSAPI, túneles y autenticación.
- Validar scripts de automatización que analizan la salida de sshd -G.
- Comprobar el funcionamiento del sandbox seccomp en Linux.
- Realizar una copia de seguridad de /etc/ssh.
- Probar la actualización en un servidor no crítico.
- Verificar el acceso mediante una segunda sesión antes de cerrar la primera.
- Revisar logs después de la actualización.
OpenSSH 10.4 modifica la salida del modo de volcado de configuración sshd -G. Los nombres de las directivas ahora aparecen con mayúsculas y minúsculas, por ejemplo PubkeyAuthentication, mientras que anteriormente se mostraban completamente en minúsculas.
Los scripts que procesan esa salida de manera sensible a mayúsculas podrían necesitar ajustes.
Buenas prácticas que siguen siendo necesarias
- Utilizar autenticación mediante claves públicas.
- Deshabilitar el acceso directo de root.
- Restringir usuarios y grupos autorizados.
- Desactivar contraseñas cuando la operación lo permita.
- Proteger las claves privadas con frase de paso.
- Limitar el acceso mediante firewall, VPN o listas permitidas.
- Supervisar intentos fallidos y accesos administrativos.
- Eliminar algoritmos antiguos solo después de comprobar compatibilidad.
- Mantener OpenSSH y el sistema operativo actualizados.
Actualizar a OpenSSH 10.4 no corrige configuraciones débiles, claves expuestas, cuentas compartidas o servidores accesibles innecesariamente desde Internet.
Preguntas clave
¿Cuándo fue publicado OpenSSH 10.4?
OpenSSH 10.4 y su versión portable 10.4p1 fueron publicados oficialmente el 6 de julio de 2026.
¿OpenSSH 10.4 corrige vulnerabilidades críticas?
Incluye varios cambios de seguridad en SFTP, SCP, sshd, autenticación y reintercambio de claves. El proyecto no asignó necesariamente un CVE individual a cada corrección en sus notas iniciales.
¿Debo compilar OpenSSH 10.4 desde el código fuente?
En servidores empresariales suele ser más seguro esperar el paquete mantenido por la distribución. Compilar manualmente puede dificultar futuras actualizaciones y romper integraciones del sistema.
¿Una versión anterior siempre es vulnerable?
No necesariamente. Las distribuciones pueden trasladar correcciones de seguridad a versiones anteriores sin cambiar el número principal mostrado por OpenSSH.
¿La criptografía poscuántica está activada automáticamente?
No. El esquema compuesto ML-DSA-44 con Ed25519 es experimental y debe habilitarse expresamente.
¿Puede OpenSSH 10.4 causar incompatibilidades?
Sí. El protocolo es más estricto durante el reintercambio de claves, seccomp pasa a ser obligatorio cuando fue habilitado durante la compilación y la salida de sshd -G cambia de formato.
¿Es necesario reiniciar todo el servidor?
Normalmente basta con validar la configuración y recargar o reiniciar el servicio SSH. Sigue siempre las instrucciones del proveedor de tu distribución.
Recomendamos
En resumen
OpenSSH 10.4 es una actualización importante para administradores de sistemas y responsables de seguridad. Corrige problemas en SFTP, SCP, internal-sftp, GSSAPI, reenvío, autenticación y reintercambio de claves.
La versión también endurece el uso de seccomp en Linux e incorpora una opción experimental de firma poscuántica que combina ML-DSA-44 con Ed25519.
Las empresas deberían revisar la disponibilidad de paquetes en su distribución, evaluar posibles incompatibilidades y probar la actualización antes de aplicarla masivamente. El número de versión no debe ser el único criterio: también es necesario comprobar los avisos y backports publicados por cada proveedor.
Conclusión editorial
OpenSSH 10.4 no cambia la manera básica de conectarnos a un servidor, pero fortalece componentes que sostienen millones de accesos administrativos. Actualizar con planificación, probar compatibilidad y mantener una configuración segura sigue siendo esencial para proteger la infraestructura.
