Resumen

  • SSH_AGENTC_SIGN_REQUEST entrega al agente una clave pública, datos e indicadores; la respuesta devuelve una firma o un fallo. Ese intercambio no incluye campos obligatorios para la identidad del proceso, la persona, la máquina remota, la cuenta o la finalidad.
  • El protocolo del agente no autentica por sí mismo al cliente ni protege el transporte. El sistema anfitrión debe controlar el punto de acceso, y reenviar el agente delega capacidad de uso aunque el material privado permanezca en origen.
  • Confirmación, caducidad, bloqueo, firma, autenticación del servidor y autorización posterior son decisiones distintas. Un recibo de intención en seis etapas puede unirlas sin almacenar claves, frases secretas ni el contenido sensible firmado.

La evidencia tranquilizadora puede ser incompleta

En una revisión de acceso aparece una secuencia aparentemente concluyente: el agente respondió correctamente, el verificador acepta la firma y el inventario del dispositivo muestra que la clave privada nunca salió. Falta, sin embargo, la pregunta política. ¿Qué proceso alcanzó el agente? ¿La solicitud fue local o cruzó un canal reenviado? ¿Qué restricciones estaban activas en ese instante? ¿Qué información vio quien pulsó el botón de confirmación? ¿El servidor aceptó esa clave para esa cuenta, exigió otro factor o rechazó el intento?

El RFC 9987, publicado en mayo de 2026 como Proposed Standard del IETF, normaliza el protocolo entre un cliente y un componente capaz de guardar claves privadas o delegar su uso. El cliente dirige la conversación: puede añadir y retirar identidades, enumerarlas, pedir firmas, bloquear el agente o invocar extensiones. Es una interfaz deliberadamente limitada. Definir bien sus mensajes no convierte al agente en intérprete de la intención humana ni de la política del servicio final.

La solicitud de firma contiene el blob de clave pública, una cadena de datos y flags. La respuesta satisfactoria contiene la firma. No hay un campo requerido para el ejecutable iniciador, la identidad humana, el host destino, el usuario remoto, la orden, el ticket de cambio o la regla de autorización. Los datos pueden representar una autenticación SSH, pero el formato genérico no promete que sea ese su único uso. La criptografía enlaza bytes y clave; no inventa el contexto que no recibió.

Esto no es una omisión que deba corregirse ensanchando el RFC hasta convertirlo en un sistema empresarial. El error se produce cuando el panel de operaciones presenta «firma generada» como «acción consentida». Why BTW Media Exists insiste en conservar la distancia entre lo observado y lo atribuido. Aquí se observó el uso de una clave. Consentimiento y autorización son afirmaciones adicionales.

Custodiar el secreto no limita automáticamente su uso

La sección de seguridad del RFC 9987 señala que el protocolo de agente carece de autenticación del cliente y de seguridad de transporte propias. En instalaciones habituales viaja por un socket local o una canalización cuyo acceso restringe el sistema operativo. Alcanzar ese extremo suele bastar para solicitar operaciones con las identidades disponibles. La lista de quienes pueden usar la clave depende, por tanto, de la frontera del canal y no solo del lugar donde reposan los bytes privados.

Un proceso hostil quizá no pueda extraer la clave de un agente o un token, pero sí pedirle firmas si la interfaz está expuesta y la identidad no tiene restricciones. El estándar advierte además que un agente sin restricciones puede servir de oráculo muy favorable para observación lateral. «No exportable» responde a una pregunta de custodia. No responde a la legitimidad de cada invocación.

Con tokens físicos también conviene separar inventarios. Añadir una identidad al agente puede delegar la operación al token; retirarla del agente no debería borrar la clave del token. Un registro de emergencia que diga «clave retirada» necesita precisar de qué capa, qué sesión y qué época. De lo contrario, el equipo puede creer revocado un camino mientras otro permite volver a cargar la misma capacidad.

The Policy Mirror ayuda a repartir responsabilidades según el control real. El sistema operativo admite al cliente del agente. El agente aplica sus restricciones. El token protege el material y quizá exige presencia. El servidor decide si la clave autentica la cuenta. La aplicación o el servicio decide lo que esa sesión puede hacer. Ninguna capa hereda el dictamen de las otras por el hecho de compartir una firma.

Las restricciones tienen historia

RFC 9987 permite cargar una clave con tiempo de vida o con confirmación explícita antes de cada operación privada. Las extensiones pueden añadir límites. Si el agente no entiende una restricción solicitada, debe fallar la carga, no guardar la clave silenciosamente sin ella. Este principio evita una degradación invisible, pero la evidencia aún debe demostrar qué conjunto estaba activo.

Si la misma clave se añade otra vez, la solicitud nueva debería sustituir las restricciones anteriores; alternativamente, el agente puede negarse. Una huella digital no identifica por sí sola el alcance de la clave. Hace falta una época de carga o reemplazo que una la operación al tiempo de vida, la confirmación, las extensiones y el estado de bloqueo vigentes en ese momento. El estado observado después del incidente puede no ser el estado histórico.

La palabra «confirmación» también necesita precisión. Un clic acredita una respuesta de interfaz. Solo se acerca al consentimiento informado si la pantalla describió de forma segura el protocolo, destino, cuenta y consecuencia pertinentes. Mostrar los bytes íntegros puede revelar material sensible; mostrar «¿permitir uso de la clave?» es demasiado abstracto. La mejor práctica es presentar un resumen comprensible y ligar su versión a un hash de los datos exactos, sin trasladar el secreto a la telemetría.

El bloqueo del agente es otra decisión independiente. Mientras está bloqueado debe suspender, como mínimo, las firmas privadas hasta recibir la frase correcta. El desbloqueo cambia la disponibilidad de la capacidad. No identifica al próximo solicitante ni da permiso general para todos los destinos. Tratarlo como consentimiento permanente multiplica el alcance de un acto local y temporal.

Reenviar el agente mueve autoridad

El reenvío resulta útil porque una máquina remota puede solicitar una firma sin poseer la clave privada. La propiedad de custodia es auténtica, pero también lo es la delegación. RFC 9987 describe el reenvío como confianza transitiva, recomienda no activarlo por defecto y advierte contra usarlo con hosts no plenamente confiables. Un atacante en el host remoto puede invocar la clave a través del canal sin llegar a copiarla.

La atribución tiene límites estructurales. agent-connect no incluye un identificador que distinga el canal de sesión que originó la conexión. Una conexión SSH puede contener varias sesiones, y el agente local puede recibir múltiples conexiones reenviadas. El dato «llegó por este transporte» no siempre permite afirmar «lo pidió este shell, este proceso o esta persona».

La lección de Running Code Primary es observar los límites que realmente operaron: propiedad y permisos del socket, identidad disponible del par, elección de reenvío, restricciones activas, tiempos y resultado del verificador. Una política declarativa contra el reenvío no reconstruye por sí sola el recorrido de una firma concreta.

Autenticar es una decisión del sistema receptor

El RFC 4252 ubica el veredicto de autenticación de clave pública en el servidor. La firma cubre el identificador de sesión y campos que incluyen usuario, servicio, método, algoritmo y clave. El servidor comprueba la firma y evalúa si esa clave es válida para la cuenta solicitada. Incluso puede exigir más factores. La señal final de éxito es SSH_MSG_USERAUTH_SUCCESS, no la respuesta previa del agente.

El RFC 4253 define el transporte y el identificador de sesión; el RFC 4254 regula canales y servicios posteriores; el RFC 4251 explica la arquitectura completa. La estratificación conserva tres hechos diferentes: una clave firmó, el servidor autenticó y una política posterior permitió o negó una acción.

Los nombres registrados tampoco conceden autoridad. El RFC 8332 especifica RSA con SHA-2; el RFC 8709, Ed25519 y Ed448; el RFC 8308, negociación de extensiones. El registro de parámetros SSH de IANA permite interoperar con identificadores comunes. No demuestra que una técnica esté desplegada, que un agente sea accesible o que una operación tenga aprobación.

Un recibo de intención que no copie secretos

Daniel Kade propone encadenar seis etapas. La primera registra la admisión del solicitante: ruta local o reenviada, evidencia mínima del extremo, versión de política e identificador opaco. La segunda registra el estado de la clave: huella pública, ámbito visible, época de carga, caducidad, confirmación, extensiones, delegación al token y bloqueo.

La tercera registra la operación mediante longitud y hash resistente de los datos exactos, algoritmo y flags. La cuarta conserva si hubo confirmación, qué descripción segura se mostró, qué superficie confiable recogió la decisión y si fue aprobación, denegación o indisponibilidad. La quinta anota el dictamen del agente y la clase de error. La sexta recoge el resultado del sistema receptor: protocolo, destino, sesión, cuenta, verificación, factores pendientes y autorización posterior.

El esquema no forma parte del RFC 9987 y no pretende que el agente conozca el negocio. Su función es impedir que una respuesta estrecha sustituya a toda la cadena de autoridad.

Fuentes