OpenSSH 10.3 ya está disponible e introduce una combinación de parches de seguridad, modificaciones de comportamiento y nuevas capacidades que impactan tanto a administradores de sistemas como a desarrolladores. Aunque muchas de las novedades son técnicas, varias de ellas pueden provocar fallos de conexión con clientes o servidores antiguos si no se revisan las configuraciones con cuidado.

Para entornos corporativos, donde OpenSSH es una pieza básica en servidores Linux, sistemas BSD y dispositivos de red, esta actualización resulta especialmente relevante. La versión 10.3 arregla vulnerabilidades, ajusta la validación de certificados y cambia el tratamiento de ciertas opciones de configuración, por lo que conviene probarla en entornos de preproducción antes de desplegarla de forma masiva.

Compatibilidad rota con implementaciones sin rekeying

Uno de los cambios más delicados de OpenSSH 10.3 es que se elimina el código de «bug-compatibilidad» con implementaciones que no soportan rekeying. Hasta ahora, el proyecto mantenía una serie de ajustes internos que permitían seguir hablando con clientes o servidores SSH antiguos o no estándar que carecían de esta capacidad de renegociar claves durante la sesión.

A partir de esta versión, si un cliente o servidor SSH no admite rekeying, la conexión con OpenSSH 10.3 simplemente fallará al intentar establecerse o durante la sesión. Esto puede afectar a infraestructuras que todavía usen software heredado, dispositivos embebidos o soluciones propietarias que implementan el protocolo SSH de forma incompleta.

Los responsables de sistemas en organizaciones deberían inventariar dispositivos y servicios SSH para comprobar si todos soportan rekeying antes de actualizar. En despliegues donde se mantengan equipos antiguos o software personalizado, puede ser necesario actualizar esos componentes o aislarlos en segmentos donde no se emplee OpenSSH 10.3.

Corrección de fallo de inyección de comandos vía nombre de usuario

En el cliente ssh se corrige una vulnerabilidad de validación que, bajo ciertas condiciones, permitía que caracteres especiales de la shell presentes en el nombre de usuario se expandieran antes de la comprobación de seguridad. El problema aparece cuando se usan nombres de usuario controlados por terceros y configuraciones avanzadas con tokens de sustitución.

Concretamente, la vulnerabilidad afectaba a configuraciones que incluyen el token %u dentro de bloques Match exec en el archivo ssh_config. En ese escenario, un atacante con la capacidad de influir en el nombre de usuario pasado al comando ssh podría llegar a ejecutar órdenes arbitrarias en la shell, aprovechando la expansión de metacaracteres.

La nueva versión ajusta el orden de validación de estos parámetros para evitar la expansión peligrosa de nombres de usuario maliciosos. Aun así, los desarrolladores recuerdan que exponer los argumentos de la línea de comandos de ssh a entrada no confiable sigue siendo una mala práctica de diseño, especialmente en scripts o herramientas automatizadas utilizadas en grandes entornos.

Cambios en el tratamiento de certificados y principales

OpenSSH 10.3 introduce varios ajustes significativos en la gestión de certificados SSH y sus «principals» (identidades a las que se asocia el certificado), con impacto directo en cómo se validan los accesos.

Bug en la coincidencia de principales con comas

Se ha corregido un error en sshd al comparar la opción principals=»» de las entradas en authorized_keys con la lista de principales incluida en un certificado. El fallo se producía cuando uno de los nombres de principal en el certificado contenía una coma, lo que podía llevar a coincidencias inadecuadas en escenarios muy concretos.

Para que el problema fuese explotable, debían darse varias condiciones: que la entrada de authorized_keys incluyera más de un principal, que la autoridad certificadora emitiera un certificado con varios de esos nombres separados por comas y que se emplearan claves de CA definidas por el propio usuario (user-trusted CA keys). El flujo principal de autenticación por certificados basado en TrustedUserCAKeys y AuthorizedPrincipalsFile no se veía afectado por este bug.

Certificados con lista de principales vacía

Otro cambio de comportamiento corrige un diseño histórico problemático en certificados. Hasta ahora, cuando un certificado con la sección de principales vacía se usaba junto con authorized_keys principals=»», se trataba de facto como un comodín, de manera que permitía autenticarse como cualquier usuario que confiara en la misma autoridad certificadora.

Esto suponía un riesgo no evidente: una CA que emitiera por error un certificado con lista de principales vacía estaba otorgando sin querer un acceso extremadamente amplio. En OpenSSH 10.3, esta situación cambia y un certificado sin principales pasa a considerarse como que no coincide con ningún principal, evitando ese comportamiento de tipo «wildcard» tan peligroso.

Además, el proyecto ha unificado el tratamiento de comodines en principales de certificados: se admite el uso de wildcards en certificados de host, pero no en certificados de usuario. Con ello se busca un comportamiento más predecible y fácil de auditar, algo especialmente valorado en auditorías de seguridad en organizaciones europeas sujetas a marcos como NIS2 o ENS.

Aplicación estricta de algoritmos ECDSA

En la parte criptográfica, OpenSSH 10.3 corrige un problema en la aplicación de las directivas PubkeyAcceptedAlgorithms y HostbasedAcceptedAlgorithms para claves ECDSA. Hasta esta versión, si aparecía el nombre de un algoritmo ECDSA en cualquiera de estas listas, el servidor aceptaba de facto otros algoritmos ECDSA aunque no estuvieran enumerados explícitamente.

Con la nueva revisión, sshd respeta de forma precisa la lista de algoritmos permitidos, cerrando ese hueco y ofreciendo un control más fino sobre qué variantes ECDSA pueden utilizarse. Esto resulta útil para administradores que buscan limitar el conjunto de algoritmos a perfiles más robustos o alinearse con recomendaciones de seguridad nacionales.

Corrección en scp al descargar como root

La herramienta scp también recibe un ajuste de seguridad cuando se usa en modo legado (compatibilidad con rcp) y se ejecuta como root. En versiones anteriores, al descargar ficheros sin usar la opción -p, el programa no eliminaba los bits setuid y setgid de los archivos recibidos.

Esta conducta, heredada del rcp original de Berkeley, podía resultar peligrosa en ciertos flujos de copia, ya que un archivo transferido con permisos especiales podría ejecutarse con privilegios elevados en el sistema destino. OpenSSH 10.3 corrige este comportamiento para reforzar la seguridad en administraciones remotas, algo muy habitual en servidores de producción en centros de datos.

Validación reforzada de ProxyJump y control de multiplexación

En cuanto a las opciones avanzadas de conexión, el cliente introduce mejoras en ProxyJump (parámetro -J o -oProxyJump). Ahora, los valores de usuario y host pasados por línea de comandos se validan de forma más estricta para evitar posibles vectores de inyección de comandos en configuraciones donde estos campos puedan verse influidos por entrada no confiable.

Es importante destacar que esta validación solo se aplica a lo recibido por la línea de comandos y no afecta a los valores definidos dentro de los archivos de configuración. Aun así, supone una capa adicional de protección para scripts, automatizaciones y herramientas que utilicen ProxyJump de manera dinámica.

En el terreno de la multiplexación de conexiones, se ha solucionado un problema con la confirmación de sesiones cuando se usaba ControlMaster ask/autoask en modo proxy mediante «ssh -O proxy». Antes, las solicitudes de confirmación no se evaluaban correctamente en este tipo de sesiones multiplexadas.

Además, se añaden nuevos comandos para obtener información detallada sobre sesiones activas. El comando «ssh -O conninfo» y la secuencia de escape «~I» muestran datos de la conexión para sesiones en curso, mientras que «ssh -O channels» informa de qué canales mantiene abiertos el proceso multiplexor. Estas funcionalidades pueden facilitar el diagnóstico de problemas en despliegues complejos, muy habituales en grandes organizaciones y proveedores de servicios en la UE.

Novedades en ssh-agent, ssh-add y gestión de claves

OpenSSH 10.3 da un paso más en la alineación con el borrador IETF draft-ietf-sshm-ssh-agent en materia de agente SSH. Se añaden compatibilidades con los nuevos codepoints asignados por IANA para reenvío de agente, de forma que, cuando el servidor anuncie soporte de esos nombres mediante el mensaje EXT_INFO, OpenSSH priorice el uso de los identificadores estandarizados.

No obstante, se mantiene el soporte para las extensiones históricas con sufijo @openssh.com, garantizando la interoperabilidad con infraestructuras ya desplegadas. El componente ssh-agent incorpora también soporte para la extensión «query» definida en el mismo borrador, lo que permite consultar capacidades del agente de forma más estructurada.

Por su parte, la utilidad ssh-add suma la opción -Q para preguntar por las extensiones de protocolo que soporta el agente. Esta funcionalidad resulta especialmente útil para equipos de seguridad y operaciones que necesitan comprobar qué características están disponibles en los agentes desplegados en diferentes sistemas.

En el ámbito de las claves, ssh-keygen incluye ahora la posibilidad de escribir claves ED25519 en formato PKCS8, lo que facilita su integración con otras herramientas y librerías criptográficas empleadas en entornos empresariales y de administración pública.

Penalizaciones por origen y mejoras de diagnóstico en sshd

El servidor SSH incorpora mejoras orientadas a mitigar abusos y facilitar la observabilidad. Una de ellas es la introducción de la penalización invaliduser dentro de PerSourcePenalties, que se aplica cuando se reciben intentos de inicio de sesión con nombres de usuario que no existen en el sistema.

Por defecto, esta nueva penalización consiste en una espera de cinco segundos, en línea con el castigo ya existente para authfail, pero los administradores pueden configurar duraciones mayores si detectan ataques de fuerza bruta o barridos masivos de usuarios. Además, la resolución temporal de las penalizaciones pasa a ser de coma flotante, permitiendo establecer castigos inferiores al segundo en escenarios de eventos de alta frecuencia.

En paralelo, las nuevas capacidades de multiplexación descritas anteriormente («ssh -O conninfo», «ssh -O channels» y el escape «~I») proporcionan más visibilidad sobre las conexiones activas, lo que puede ser de gran ayuda a la hora de diagnosticar problemas de latencia, bloqueos o uso anómalo de túneles y canales SSH.

Más cambios en seguridad y compatibilidad

OpenSSH 10.3 añade en sshd la opción de servidor GSSAPIDelegateCredentials, que controla si el servidor acepta o no credenciales delegadas ofrecidas por el cliente. Esta opción refleja la ya existente en el lado cliente y permite adaptar el comportamiento a las políticas internas de cada organización sobre delegación de credenciales Kerberos y similares.

Se amplía también el alcance de las directivas RevokedHostKeys en ssh_config y RevokedKeys en sshd_config, que ahora pueden apuntar a múltiples ficheros. De esta manera, es más sencillo gestionar listas de claves revocadas separadas por proyectos, departamentos o niveles de confianza, algo útil en grandes infraestructuras donde conviven múltiples equipos y proveedores.

La versión corrige, además, un conjunto de problemas prácticos: se soluciona un fallo en la entrada de PIN para claves PKCS#11 introducido en las versiones 10.1 y 10.2, se mejora el manejo de firmas de certificados FIDO/WebAuthn, se corrige un crash de sshd relacionado con directivas de subsistemas ausentes dentro de bloques Match y se aborda un problema de confusión de nombre de usuario en el módulo PAM en la rama portable.

Con este lanzamiento, OpenSSH 10.3 consolida un paquete de cambios amplio que refuerza la seguridad, ajusta comportamientos heredados y amplía capacidades de gestión sin perder compatibilidad con la mayoría de despliegues modernos. Las organizaciones que dependan de SSH para administración remota, automatización y túneles seguros harían bien en planificar la actualización, revisando antes sus entornos de pruebas para detectar posibles problemas con implementaciones antiguas, opciones poco usuales o configuraciones muy personalizadas.