Bloquear el agente SSH desactivaba sus propias restricciones

Hay una costumbre bastante extendida entre quienes administramos servidores: bloquear el agente SSH con ssh-add -x cuando uno se levanta de la mesa, y desbloquearlo al volver. Suena razonable. El 11 de agosto, OpenSSH publicó la versión 10.5 y uno de los tres arreglos de seguridad dice, en resumen, que con el agente bloqueado las sesiones de reenvío se trataban como locales en vez de como remotas.

Local y remoto no son etiquetas decorativas dentro del agente: son exactamente la frontera que decide qué se puede hacer con tus claves. Este post va de por qué pasaba, a quién le afecta de verdad, y de un detalle que nos parece más importante que el fallo en sí: el fallo tiene su número de CVE desde el mismo día, puntúa 3,5 sobre 10 y con esa nota no entra en la lista de tareas de nadie.

Lo que dice la nota de publicación

El texto de OpenSSH es corto y conviene leerlo entero antes de opinar. Sobre ssh-agent: «fix an interaction between agent locking and the [email protected] extension that is used to identify forwarded agents. These binding requests were refused when the agent was locked, with the result that operations that were intended to be limited to local use only could be performed remotely, including the ability to add PKCS#11 tokens and make use of keys that had destination restrictions applied». Lo reportó sn0x-sharma.

El mensaje del commit que lo corrige, del 7 de agosto, es todavía más directo que la nota: «Allow [email protected] requests when the agent is locked, otherwise forwarding sessions established with an agent was locked will be treated as local, rather than remote». En castellano: permitir las peticiones de session-bind aunque el agente esté bloqueado, porque si no, las sesiones de reenvío establecidas mientras lo estaba se tratan como locales en vez de como remotas. La errata del original —«with an agent was locked»— es suya; la reproducimos tal cual. Cuatro días después salía la versión.

Qué marca «esto viene de fuera»

Para entender el efecto hay que saber una cosa del protocolo del agente que Damien Miller escribió en 2022 y que sigue siendo el mejor resumen del problema: «Un agente reenviado parece efectivamente idéntico a uno local, ya que (hasta ahora) el protocolo no ofrecía forma de distinguirlos». Esa frase es de la documentación con la que OpenSSH 8.9 (febrero de 2022) presentó las restricciones de agente.

Lo que 8.9 añadió fue precisamente la forma de distinguirlos. El cliente ssh envía un mensaje [email protected] como primer mensaje de cada conexión al agente, y ese mensaje enlaza criptográficamente el identificador de sesión SSH con la clave de host del servidor. Con esa cadena de enlaces, el agente puede reconstruir por dónde ha viajado una petición y aplicar las restricciones de destino que le pusiste a una clave al añadirla con ssh-add -h.

Una precisión honesta, porque no queremos venderlo más grande de lo que es: OpenSSH no publica la secuencia exacta de la explotación. La ventana que se deduce de la corrección es estrecha —una sesión de reenvío establecida mientras el agente estaba bloqueado, usada después—, y encaja con la complejidad alta de ataque que le asigna su propia ficha de CVE. Lo que sí está documentado es la propiedad que se rompía y las dos consecuencias que el proyecto nombra: añadir tokens PKCS#11 y usar claves con restricciones de destino desde el otro lado del reenvío.

A quién le toca esto de verdad

Para que el fallo tenga consecuencias hacen falta tres cosas a la vez:

Ese tercer punto es el que nos parece más interesante para una pyme con un servidor de salto. La documentación de OpenSSH lleva desde 2022 diciendo que «en general es mejor que los usuarios eviten del todo el uso de un agente reenviado (por ejemplo, usando la directiva ProxyJump)». Quien siguió ese consejo hace cuatro años no tiene nada que revisar hoy. Quien montó el reenvío y luego le puso restricciones para dormir tranquilo es justo el perfil al que el arreglo le importa.

Los otros dos arreglos, en su justa medida

El segundo es un posible uso de memoria después de liberarla en el cliente (sobre datos de realloc), cuando se añade un reenvío remoto por el socket de multiplexación local mientras hay una petición de apertura pendiente con el servidor. Lo notificó y lo arregló Brian Mingus, de Cognatory. El tercero corrige que la palabra restrict de authorized_keys —la que uno pone para decir «esta clave no puede hacer nada más que lo que yo habilite»— no se aplicaba también al reenvío de túneles. Lo reportó Erichen, del Instituto de Tecnología de la Computación de la Academia China de las Ciencias.

El propio OpenSSH añade entre paréntesis que el reenvío de túneles «está deshabilitado administrativamente por defecto», y eso es un matiz que hay que respetar: si nunca activaste PermitTunnel, ese tercer fallo no te abre nada. Nos parece una forma sana de documentar un bug, y por eso lo repetimos aquí en vez de titular con los tres a la vez.

Hay un dato que conviene contar aparte: dos de los tres arreglos son del lado cliente (ssh-agent y ssh) y solo uno es del servidor. La mayoría de inventarios de parcheo que vemos apuntan a servidores. El portátil desde el que un administrador se conecta a todo suele actualizarse cuando su sistema operativo decide, y no cuando OpenSSH publica.

Tienen número, y aun así no mueven nada

Los tres fallos tienen su CVE desde el mismo 11 de agosto: CVE-2026-73281 para el del agente, CVE-2026-73282 para el del cliente y CVE-2026-73283 para el de restrict. Y con ellos vienen sus notas: 3,5, 4,8 y 2,5 sobre diez. Ninguna llega a «media-alta», que es el umbral con el que la mayoría de organizaciones —también las que nos contratan— filtran lo que merece una ventana de mantenimiento y lo que espera al ciclo trimestral.

La nota está bien puesta, y ese es el problema interesante. El vector del fallo del agente dice complejidad alta, privilegios locales necesarios y ningún impacto sobre la confidencialidad ni la disponibilidad: eso es un 3,5 honesto. El CVSS mide el daño que se hace, y aquí el daño directo es pequeño. Lo que no mide, porque no está diseñado para medirlo, es que has dejado de tener un control que creías tener. Tus restricciones de destino no se rompen ruidosamente: se quedan sin aplicar.

Y el otro eslabón tampoco corre. Consultando hoy el rastreador de Debian, la versión de OpenSSH empaquetada es 10.4p1-4 en sid (inestable), 10.0p1 en Debian 13 trixie y 9.2p1 en Debian 12 bookworm. Cinco días después de la publicación, la 10.5 no ha llegado ni siquiera a inestable. No es un reproche: así funciona una distribución estable, y ese ritmo pausado es la razón por la que la mayoría preferimos que sea la distribución quien nos actualice. Pero conviene saber que el reloj de arriba y el de abajo no son el mismo, como ya escribimos esta misma mañana sobre lo que apt no te va a contar cuando Proxmox VE 8 salga de soporte.

Debian ya lo ha decidido, además, y lo ha dejado escrito. En la ficha de los tres CVE, la anotación para trixie es <no-dsa> (Minor issue): no habrá aviso de seguridad dedicado, se corregirá cuando toque. El estado en inestable es (unfixed), con el fallo abierto como el bug 1144192 de Debian, y las cuatro suites —de bullseye a sid— figuran marcadas como vulnerables. Todo eso es coherente y defendible desde el lado de Debian; simplemente conviene leerlo entero antes de dar por hecho que «está en el tracker» significa que va a llegar solo la semana que viene.

Por qué esta versión llegó a los treinta y seis días

La 10.4 salió el 6 de julio y la 10.5 el 11 de agosto: treinta y seis días. Entre la 10.3 y la 10.4 habían pasado noventa y cinco, y entre la 10.2 y la 10.3, ciento setenta y cuatro. El proyecto ya ha publicado deprisa cuando ha hecho falta —entre la 10.1 y la 10.2 pasaron cuatro días—, así que lo que llama la atención no es la velocidad puntual sino que esta vez la expliquen. La nota lo dice sin rodeos: «Recientemente el equipo de OpenSSH ha recibido un gran número de informes de fallos de seguridad, muchos de los cuales son hallazgos de modelos de IA o hechos con asistencia de IA» (traducción nuestra). Y añaden acto seguido el matiz que se les suele recortar: «Si bien de muchos informes de IA se determina que no tienen impacto de seguridad cuando se consideran en el contexto de un modelo de amenaza realista, damos la bienvenida a estos informes».

El argumento que decide la cuestión, sin embargo, es el siguiente: «Hemos visto varios casos en los que un fallo de seguridad identificado por herramientas de IA es descubierto después de forma independiente por otro investigador. Esto sugiere que los adversarios que no reportan fallos a los proyectos de código abierto probablemente también sean capaces de descubrirlos» (traducción nuestra). Por eso, dicen, van a publicar más a menudo, y lo formulan con una cautela que conviene respetar: por ahora harán versiones más frecuentes «para poner los arreglos en manos de los usuarios más deprisa, en vez de agruparlos hasta la siguiente versión planificada».

Ahí lo que ha cambiado es la exclusividad del hallazgo: si una herramienta al alcance de cualquiera encuentra algo, hay que asumir que otro con la misma herramienta y menos intención de avisar lo encontrará también. Es la misma aritmética que comentábamos hablando de lo poco que duró el «no hay constancia de explotación» de vCenter, y el motivo por el que el año pasado nos pusimos a mirar en serio qué pasa cuando el atacante automatiza su parte del trabajo. Un proyecto que decide publicar antes te está diciendo que ha recalculado su ventana. Si tu ventana de mantenimiento sigue siendo trimestral, la distancia entre las dos la pagas tú.

Lo que estamos revisando esta semana

Lo que no vamos a hacer

La parte que se queda

Lo que nos llevamos a la próxima revisión de un cliente tiene poco que ver con esta versión concreta. Las palancas de restricción —el bloqueo, el restrict, las restricciones de destino— son código como el resto y fallan como el resto, con una diferencia: cuando fallan, nadie se entera. Su trabajo consiste en que no pase nada, y no pasar nada se parece muchísimo a funcionar. Desde 2022, las restricciones de destino del agente no habían dado un solo problema visible; seguirían sin darlo si sn0x-sharma no hubiera mirado. Conviene recordar además que Damien Miller las presentó en su día como un conjunto experimental.

Por eso hacemos las revisiones de acceso comprobando qué permite hoy una configuración, y no leyendo lo que alguien escribió el día que la montó. En un modelo de acceso Zero Trust bien montado, cada control se da por bueno solo después de probarlo, empezando por el que compraste precisamente para quedarte tranquilo.

Fuentes (verificadas el 16 de agosto de 2026): notas de publicación de OpenSSH 10.5 (11-ago-2026), 10.4 (6-jul-2026), 10.3 (2-abr-2026), 10.2 (10-oct-2025), 10.1 (6-oct-2025) y 8.9 (23-feb-2022), de donde salen el texto de los tres arreglos de seguridad, el párrafo sobre informes asistidos por IA y los intervalos entre versiones — openssh.com/releasenotes.html; mensaje del commit del arreglo del agente (7-ago-2026, 6a57081dc3) en el repositorio openssh-portable; fichas de CVE-2026-73281, CVE-2026-73282 y CVE-2026-73283 en MITRE (publicadas el 11-ago-2026, con CVSS 3.1 de 3,5, 4,8 y 2,5); estado, anotación <no-dsa> (Minor issue) y bug 1144192 en security-tracker.debian.org, más las versiones empaquetadas en sources.debian.org; documento «SSH agent restriction» de Damien Miller (última modificación 10-ene-2022) para el funcionamiento de [email protected], ssh-add -h y la recomendación de ProxyJump — openssh.com/agent-restrict.html. Las citas en castellano de textos originalmente en inglés son traducción nuestra. La lectura sobre la ventana de explotación y sobre lo que el CVSS no mide es nuestra, no de las fuentes.