¿Clave SSH copiada o agente reenviado? Dos riesgos distintos

Un inicio de sesión que usa una clave SSH a través de una VPN no significa que la clave privada se haya entregado al operador de la red, y esa tranquilidad es más estrecha de lo que la gente escucha. La autenticación de clave pública envía una clave pública y una firma que el cliente produce localmente. El reenvío de agente es una disposición distinta con una exposición distinta, y puede dejar una capacidad de autenticación utilizable en una máquina que usted no controla. La respuesta que debe depende de cuál de las dos cosas ocurrió realmente.

Qué envía la autenticación de clave pública

En el método estándar de clave pública el cliente ofrece una clave pública, el servidor decide si acepta esa clave, y el cliente firma un desafío con la clave privada, que permanece en su archivo o en su agente. Lo que cruza la red es la clave pública y la firma resultante. Nada en ese intercambio exige que el servidor, el túnel o cualquiera en la ruta posea el material privado.

La especificación de autenticación define esa prueba, y la clave privada no es un campo de la solicitud.

Eso es una afirmación sobre un protocolo, no una referencia de carácter para cada extremo implicado. La comprobación de la identidad del host todavía tiene que estar intacta, porque un servidor que no puede demostrar quién es puede estar recogiendo firmas para un propósito que usted no pretendía. Una VM alquilada, un bastión heredado y un portátil con una extensión desconocida son tres preguntas de confianza separadas. Manténgalas separadas de la criptográfica, que está genuinamente resuelta.

Qué delega el reenvío de agente

El reenvío de agente abre un canal desde el host remoto de vuelta al agente de su máquina, de modo que los procesos de ese host pueden pedir al agente que firme sin poseer nunca la clave privada. La clave se queda donde está, y la capacidad no. Cualquier cosa que pueda alcanzar ese socket reenviado en el host remoto, durante la vida de la sesión, puede solicitar operaciones de autenticación como una de las identidades cargadas. Eso es autoridad delegada, y por eso el reenvío merece una política más estrecha que entregar una clave pública.

Un archivo de clave copiado es una divulgación. Un agente reenviado es un permiso, y los dos necesitan respuestas distintas.

Active el reenvío para una necesidad nombrada y unos hosts nombrados, y compruebe qué hace realmente el cliente en lugar de lo que la configuración parece decir. Lo que importa son los ajustes efectivos, porque un bloque de host anula silenciosamente un valor global predeterminado. El mismo razonamiento se aplica en el lado del servidor, que puede rechazar el reenvío por completo cuando el despliegue nunca lo necesita.

Lea las pruebas antes de elegir una respuesta

Si se cree que un archivo de clave privada o una identidad de firma equivalente ha quedado expuesto, la respuesta es la sustitución y la revocación mediante el proceso de su organización, además de retirar su aceptación de cada servicio que confiaba en él. Borrar una copia local no invalida las copias que no puede ver.

Si la preocupación es un acceso temporal del agente, la respuesta es más estrecha: detenga la delegación innecesaria, revise las sesiones e identidades implicadas, y deje que el responsable del incidente decida si la sustitución está justificada. Las pruebas importan aquí, porque la ausencia de una exportación observada no demuestra que no se haya hecho un uso indebido de la autenticación, y un cambio de ruta por sí solo no es un diagnóstico de una clave robada. Anote qué componente era de confianza, si el reenvío estaba activado y qué se observó realmente. Luego elija la respuesta que encaje con ese registro en lugar de la más dramática disponible.

ssh-add -l
ssh -G host.example | grep -i forwardagent

Ejecútelos antes y después de un cambio para que la comparación signifique algo. Una sesión establecida antes conserva la delegación que se le concedió, diga lo que diga la configuración ahora.

Dos controles que no son intercambiables

Proteger el material privado, limitar quién puede pedir que lo firme y verificar la identidad del par son tres controles relacionados, y ninguno sustituye a otro. Un equipo que retira el reenvío sin comprobar las claves de host ha arreglado medio problema. Un equipo que rota una clave porque la ruta cambió no ha arreglado nada.

Un extremo comprometido es una cuarta pregunta, porque el software privilegiado en su propia máquina puede hacer bastante más que observar paquetes.

Clasifique el incidente en esas categorías antes de tocar nada, y dé a cada una un responsable. Mantenga un registro breve de lo que era de confianza, lo que se delegó y lo que se verificó, porque ese registro es lo que hace barata la siguiente revisión en lugar de otro debate. Si alguna categoría es desconocida, escriba desconocida en lugar de suponer el caso benigno. La distinción es práctica, no académica: decide si sustituye una credencial, revoca una sesión o simplemente deja de reenviar.