Bloquejar l'agent SSH desactivava les seves pròpies restriccions

Hi ha un costum bastant estès entre els qui administrem servidors: bloquejar l'agent SSH amb ssh-add -x quan un s'aixeca de la taula, i desbloquejar-lo en tornar. Sona raonable. L'11 d'agost, OpenSSH va publicar la versió 10.5 i un dles tres correccions de seguretat diu, en resum, que amb l'agent bloquejat les sessions de reenviament es tractaven com a locals en comptes de com a remotes.

Local i remot no són etiquetes decoratives dins de l'agent: són exactament la frontera que decideix què es pot fer amb les teves claus. Aquest post va de per què passava, a qui afecta de debò, i d'un detall que ens sembla més important que l'error en si: l'error té el seu número de CVE des del mateix dia, puntua 3,5 sobre 10 i amb aquesta nota no entra a la llista de tasques de ningú.

El que diu la nota de publicació

El text d'OpenSSH és curt i convé llegir-lo sencer abans d'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». Ho va notificar sn0x-sharma.

El missatge del commit que ho corregeix, del 7 d'agost, encara és més directe 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 català: permetre les peticions de session-bind encara que l'agent estigui bloquejat, perquè si no, les sessions de reenviament establertes mentre ho estava es tracten com a locals en comptes de com a remotes. L'errada de l'original —«with an agent was locked»— és seva; la reproduïm tal qual. Quatre dies després sortia la versió.

Què marca «això ve de fora»

Per entendre l'efecte cal saber una cosa del protocol de l'agent que Damien Miller va escriure el 2022 i que continua sent el millor resum del problema: «Un agent reenviat sembla efectivament idèntic a un de local, ja que (fins ara) el protocol no oferia cap manera de distingir-los». Aquesta frase és de la documentació amb què OpenSSH 8.9 (febrer del 2022) va presentar les restriccions d'agent.

El que 8.9 va afegir va ser precisament la manera de distingir-los. El client ssh envia un missatge [email protected] com a primer missatge de cada connexió a l'agent, i aquest missatge enllaça criptogràficament l'identificador de sessió SSH amb la clau d'host del servidor. Amb aquesta cadena d'enllaços, l'agent pot reconstruir per on ha viatjat una petició i aplicar les restriccions de destinació que vas posar a una clau en afegir-la amb ssh-add -h.

Una precisió honesta, perquè no ho volem inflar: OpenSSH no publica la seqüència exacta de l'explotació. La finestra que es dedueix de la correcció és estreta —una sessió de reenviament establerta mentre l'agent estava bloquejat, feta servir després—, i encaixa amb la complexitat alta d'atac que li assigna la seva pròpia fitxa de CVE. El que sí que està documentat és la propietat que es trencava i les dues conseqüències que el projecte anomena: afegir tokens PKCS#11 i fer servir claus amb restriccions de destinació des de l'altre costat del reenviament.

A qui afecta això de debò

Perquè l'error tingui conseqüències calen tres coses alhora:

Aquest tercer punt és el que ens sembla més interessant per a una pime amb un servidor de salt. La documentació d'OpenSSH diu des del 2022 que «en general és millor que els usuaris evitin del tot l'ús d'un agent reenviat (per exemple, amb la directiva ProxyJump)». Qui va seguir aquell consell fa quatre anys no té res a revisar avui. Qui va muntar el reenviament i després hi va posar restriccions per dormir tranquil és justament el perfil a qui l'arranjament importa.

les altres dues correccions, en la seva justa mesura

El segon és un ús de memòria després d'alliberar-la al client, quan s'afegeix un reenviament remot pel socket de multiplexació local mentre hi ha una petició d'obertura pendent amb el servidor. El va reportar i arreglar Brian Mingus, de Cognatory. El tercer corregeix que la paraula restrict d'authorized_keys —la que un posa per dir «aquesta clau no pot fer res més que el que jo habiliti»— no s'aplicava també al reenviament de túnels. El va notificar Erichen, de l'Institut de Tecnologia de la Computació de l'Acadèmia Xinesa de les Ciències.

El mateix OpenSSH afegeix entre parèntesis que el reenviament de túnels «està deshabilitat administrativament per defecte», i això és un matís que cal respectar: si mai no vas activar PermitTunnel, aquest tercer error no t'obre res. Ens sembla una manera sana de documentar un bug, i per això ho repetim aquí en comptes de titular amb els tres alhora.

Hi ha una dada que convé explicar a part: dos dles tres correccions són del costat client (ssh-agent i ssh) i només un és del servidor. La majoria d'inventaris de pedaçat que veiem apunten a servidors. El portàtil des del qual un administrador es connecta a tot sol actualitzar-se quan el seu sistema operatiu ho decideix, i no quan OpenSSH publica.

Tenen número, i tot i així no mouen res

Els tres errors tenen el seu CVE des del mateix 11 d'agost: CVE-2026-73281 per al de l'agent, CVE-2026-73282 per al del client i CVE-2026-73283 per al de restrict. I amb ells vénen les seves notes: 3,5, 4,8 i 2,5 sobre deu. Cap arriba a «mitjana-alta», que és el llindar amb què la majoria d'organitzacions —també les que ens contracten— filtren què mereix una finestra de manteniment i què espera al cicle trimestral.

La nota està ben posada, i aquest és el problema interessant. El vector de l'error de l'agent diu complexitat alta, privilegis locals necessaris i cap impacte sobre la confidencialitat ni la disponibilitat: això és un 3,5 honest. El CVSS mesura el mal que es fa, i aquí el mal directe és petit. El que no mesura, perquè no està dissenyat per fer-ho, és que has deixat de tenir un control que et pensaves que tenies. Les teves restriccions de destinació no es trenquen amb soroll: es queden sense aplicar.

I l'altra baula tampoc no corre. Consultant avui el rastrejador de Debian, la versió d'OpenSSH empaquetada és 10.4p1-4 a sid (inestable), 10.0p1 a Debian 13 trixie i 9.2p1 a Debian 12 bookworm. Cinc dies després de la publicació, la 10.5 no ha arribat ni tan sols a inestable. No és cap retret: així funciona una distribució estable, i aquest ritme pausat és la raó per la qual la majoria preferim que sigui la distribució qui ens actualitzi. Però convé saber que el rellotge de dalt i el de baix no són el mateix, com ja vam escriure aquest mateix matí sobre el que apt no t'explicarà quan Proxmox VE 8 surti de suport.

Debian ja ho ha decidit, a més, i ho ha deixat escrit. A la fitxa dels tres CVE, l'anotació per a trixie és <no-dsa> (Minor issue): no hi haurà avís de seguretat dedicat, es corregirà quan toqui. L'estat a inestable és (unfixed), amb l'error obert com el bug 1144192 de Debian, i les quatre suites —de bullseye a sid— hi figuren marcades com a vulnerables. Tot això és coherent i defensable des del costat de Debian; simplement convé llegir-ho sencer abans de donar per fet que «és al tracker» vol dir que arribarà sol la setmana vinent.

Per què aquesta versió va arribar als trenta-sis dies

La 10.4 va sortir el 6 de juliol i la 10.5 l'11 d'agost: trenta-sis dies. Entre la 10.3 i la 10.4 n'havien passat noranta-cinc, i entre la 10.2 i la 10.3, cent setanta-quatre. El projecte ja ha publicat de pressa quan ha calgut —entre la 10.1 i la 10.2 van passar quatre dies—, així que el que crida l'atenció no és la velocitat puntual sinó que aquesta vegada l'expliquin. La nota ho diu sense embuts: «Recentment l'equip d'OpenSSH ha rebut un gran nombre d'informes d'errors de seguretat, molts dels quals són troballes de models d'IA o fets amb assistència d'IA» (traducció nostra). I hi afegeixen tot seguit el matís que se'ls sol retallar: «Tot i que de molts informes d'IA es determina que no tenen impacte de seguretat quan es consideren en el context d'un model d'amenaça realista, donem la benvinguda a aquests informes».

L'argument que decideix la qüestió, però, és el següent: «Hem vist diversos casos en què un error de seguretat identificat per eines d'IA és descobert després de manera independent per un altre investigador. Això suggereix que els adversaris que no notifiquen errors als projectes de codi obert probablement també siguin capaços de descobrir-los» (traducció nostra). Per això, diuen, publicaran més sovint, i ho formulen amb una cautela que convé respectar: de moment faran versions més freqüents «per posar les correccions a mans dels usuaris més de pressa, en comptes d'agrupar-les fins a la següent versió planificada».

Aquí el que ha canviat és l'exclusivitat de la troballa: si una eina a l'abast de qualsevol troba alguna cosa, cal assumir que un altre amb la mateixa eina i menys intenció d'avisar també ho trobarà. És la mateixa aritmètica que comentàvem parlant del poc que va durar el «no hi ha constància d'explotació» de vCenter, i el motiu pel qual l'any passat ens vam posar a mirar seriosament què passa quan l'atacant automatitza la seva part de la feina. Un projecte que decideix publicar abans t'està dient que ha recalculat la seva finestra. Si la teva finestra de manteniment continua sent trimestral, la distància entre totes dues la pagues tu.

El que estem revisant aquesta setmana

El que no farem

La part que es queda

El que ens emportem a la propera revisió d'un client té poc a veure amb aquesta versió concreta. Les palanques de restricció —el bloqueig, el restrict, les restriccions de destinació— són codi com la resta i fallen com la resta, amb una diferència: quan fallen, ningú se n'assabenta. La seva feina consisteix a fer que no passi res, i no passar res s'assembla moltíssim a funcionar. Des del 2022, les restriccions de destinació de l'agent no havien donat ni un sol problema visible; continuarien sense donar-lo si sn0x-sharma no hagués mirat. Convé recordar, a més, que Damien Miller les va presentar al seu dia com un conjunt experimental.

Per això fem les revisions d'accés comprovant què permet avui una configuració, i no llegint el que algú va escriure el dia que la va muntar. En un model d'accés Zero Trust ben muntat, cada control es dóna per bo només després de provar-lo, començant pel que vas comprar precisament per quedar-te tranquil.

Fonts (verificades el 16 d'agost del 2026): notes de publicació d'OpenSSH 10.5 (11 ag. 2026), 10.4 (6 jul. 2026), 10.3 (2 abr. 2026), 10.2 (10 oct. 2025), 10.1 (6 oct. 2025) i 8.9 (23 febr. 2022), d'on surten el text de les tres correccions de seguretat, el paràgraf sobre informes assistits per IA i els intervals entre versions — openssh.com/releasenotes.html; missatge del commit de la correcció de l'agent (7 ag. 2026, 6a57081dc3) al repositori openssh-portable; fitxes de CVE-2026-73281, CVE-2026-73282 i CVE-2026-73283 a MITRE (publicades l'11 ag. 2026, amb CVSS 3.1 de 3,5, 4,8 i 2,5); estat, anotació <no-dsa> (Minor issue) i bug 1144192 a security-tracker.debian.org, més les versions empaquetades a sources.debian.org; document «SSH agent restriction» de Damien Miller (última modificació 10 gen. 2022) per al funcionament de [email protected], ssh-add -h i la recomanació de ProxyJump — openssh.com/agent-restrict.html. Les citacions en català de textos originalment en anglès són traducció nostra. La lectura sobre la finestra d'explotació i sobre el que el CVSS no mesura és nostra, no de les fonts.