Resumen

  • RFC 9987 define un agente que guarda claves y atiende peticiones de carga, retirada, listado, bloqueo y firma. Su protocolo base no autentica al cliente: poder llegar al punto de conexión suele bastar para pedir operaciones privadas.
  • El reenvío no entrega la materia secreta al servidor intermedio. Extiende hasta él una facultad de llamada, creando confianza transitiva y la posibilidad de apropiarse del uso sin extraer la clave.
  • Las restricciones de vida, confirmación y extensión reducen esa facultad. El servidor de destino sigue decidiendo si la clave autentica una cuenta, si exige otro factor y qué canales o acciones autoriza.

Pensemos en una aprobación per-use. El ordenador muestra un aviso y el usuario acepta. El registro marca “confirmado”. ¿Qué quedó confirmado? Tal vez el aviso identificó el host, la cuenta y la huella de la solicitud. Tal vez mostró únicamente el comentario de la clave. Tal vez apareció veinte veces en un minuto y el operador respondió por hábito.

RFC 9987 exige confirmación cuando la clave lleva esa restricción, pero no diseña la interfaz humana ni prescribe el contexto visible. Esa decisión es local. Por eso, la palabra «confirmación» describe un mecanismo; no demuestra por sí sola que la persona entendió la consecuencia.

La misma disciplina debe aplicarse al agente completo. El propósito del agente es valioso: mantener la clave privada fuera de cada cliente SSH, reducir las copias en memoria y permitir que un componente pequeño o un dispositivo seguro realice la operación. Sin embargo, guardar el secreto y controlar su uso son problemas distintos.

El agente protege bytes y ofrece una función

El protocolo funciona por solicitudes y respuestas. El cliente puede añadir o quitar identidades, preguntar qué claves existen, bloquear el agente y solicitar una firma sobre datos concretos. El agente puede rechazar algoritmos, banderas, claves o contextos.

La seguridad no nace de una autenticación dentro del protocolo. RFC 9987 declara que el contrato base carece de autenticación y de protección de transporte. En un sistema Unix, permisos de socket y credenciales del proceso par suelen determinar quién llega. En Windows, lo hace el descriptor del canal. SSH_AUTH_SOCK facilita al cliente localizar el servicio.

El punto de conexión es, por tanto, una superficie de autoridad. Un proceso que no puede leer los factores privados puede aun así pedir que se firme una cadena de bytes. El RFC distingue este riesgo con precisión: impedir que el atacante copie la clave no excluye que robe su uso.

El mensaje de firma lleva el blob público, los datos y banderas. La respuesta certifica que el agente generó una firma o que la rechazó. Todavía no dice si los datos correspondían a una conexión aprobada, si el solicitante tenía mandato, si el servidor aceptó la clave o si se ejecutó algo.

Una auditoría que solo busca archivos privados responderá a la pregunta de extracción. Debe añadir otra: durante el periodo de exposición, ¿qué procesos podían convertir el agente legítimo en un oráculo de firma?

Tres restricciones, tres límites

La vida útil elimina la clave del agente tras un número de segundos desde la carga. Reduce el tiempo de llamada, pero no revoca firmas ya emitidas ni sesiones remotas ya abiertas. Tampoco demuestra que otro agente no tenga la misma identidad.

La confirmación exige una decisión explícita por operación. Es una defensa fuerte cuando el aviso aporta contexto y la frecuencia permite pensar. Es débil cuando la interfaz oculta el destino o cuando la automatización enseña al usuario a aprobar. Para respaldar un mandato humano, el registro debe conservar lo que se mostró, el resultado y la correlación con la solicitud.

Las restricciones de extensión permiten reglas nombradas por implementaciones. El agente que no entiende una de ellas debe abortar y rechazar la clave. No puede saltarla y continuar. Ese fallo cerrado protege la intención del usuario. Aun así, solo un ensayo entre cliente y agente demuestra que la regla existe en el conjunto compatible real.

El estado cambia con las cargas. Si una clave ya está presente, una nueva petición debería sustituir sus restricciones por las nuevas, o bien el agente puede rechazar el duplicado. Un reinicio, una herramienta diferente o un script pueden transformar una identidad limitada en otra sin confirmación o sin caducidad. La política efectiva se lee después de la transición.

El bloqueo detiene operaciones sensibles hasta el desbloqueo. Es un cierre local, no una revocación distribuida. Una sesión autenticada antes del bloqueo puede seguir viva y causar efectos.

Reenviar es delegar una llamada

Cuando se activa el reenvío, el servidor intermedio presenta a la sesión un socket aparente. Los mensajes de ese socket viajan por un canal hasta el cliente y su agente. El intermedio no almacena la clave; obtiene un camino operativo hacia ella.

RFC 9987 lo llama confianza transitiva. Recomienda no reenviar por defecto y no hacerlo hacia hosts que no sean plenamente confiables. También advierte que, sin controles adicionales para conexiones reenviadas, la decisión es todo o nada.

La confianza transita porque el usuario no solo confía en el servidor SSH como extremo. Confía en los procesos capaces de acceder al socket, en los administradores privilegiados, en las extensiones, en la cadena de software y en la capacidad de detectar una intrusión. Un bastión con muchos usuarios y tareas puede convertirse en un agregador de manos firmantes.

La atribución exige más que el nombre del bastión. Una sola conexión SSH puede multiplexar varias sesiones y varias conexiones al agente. agent-connect no identifica el canal de sesión que originó la petición. El cliente puede aceptar, bajo su política, una conexión aunque no exista una petición previa de sesión, y puede mantenerla después de que esa sesión cierre.

Estas opciones habilitan usos legítimos, pero rompen la deducción «esta terminal pidió esta firma». El relato debe unir identificadores y tiempos desde la conexión exterior hasta la aceptación final.

La firma está vinculada; la facultad sigue viva

En la autenticación por clave pública de SSH, el cliente no firma un mensaje genérico. RFC 4252 incluye en los datos el identificador de sesión, el usuario, el servicio, el método, el algoritmo y la clave. El servidor comprueba por separado que esa clave es aceptable para la cuenta y que la firma es válida. Puede exigir más factores.

Esto limita la reutilización de una firma capturada. La firma de una sesión no es una contraseña transportable. Pero no elimina el peligro del agente accesible: el atacante puede solicitar otra firma para una nueva sesión mientras conserve la ruta de llamada y el servidor de destino acepte la clave.

Conviene separar seis hechos: la clave está cargada; el socket es alcanzable; el agente acepta la operación; la firma corresponde al contexto; el servidor acepta clave y firma; la sesión obtiene un canal con capacidad de actuar. Un panel verde en el tercer paso no demuestra el sexto.

La política criptográfica también se distribuye. El agente puede soportar una clave RSA o Ed25519. Las banderas pueden pedir RSA con SHA-2. El servidor y la organización pueden aceptar conjuntos diferentes. El registro IANA permite coordinar nombres; no verifica qué está habilitado en una máquina concreta.

Construir una cadena probatoria

En el origen, guardar proceso y versión del agente, permisos del punto de conexión, identidad del par, huella de clave, hora de carga, restricciones efectivas, estado de bloqueo y retirada. Para dispositivos, incluir el proveedor cargado y su aislamiento.

En el salto, registrar la conexión SSH, la decisión de confianza, la petición de reenvío, cada canal de agente y su cierre. Detectar conexiones que sobreviven al canal de sesión y diferencias entre configuración explícita, heredada u oportunista.

En la firma, retener hora, clave, algoritmo, una huella segura del contexto, evaluación de restricciones y contenido de la confirmación presentada. En el destino, correlacionar cuenta, clave autorizada, validación, otros factores, canales y restricciones.

Después viene el efecto: comando, subsistema, túnel, transferencia o rechazo. Si el incidente se cierra, probar también la terminación: retirar la clave, cerrar el agente y los canales, revocar donde corresponda y observar que una nueva autenticación falla.

La frase «la clave nunca salió» puede ser cierta. Solo responde a una capa. La realidad operativa aparece cuando cada transición está conectada con evidencia.