Clave SSH copiada ou axente reenviado? Dous riscos diferentes

Un inicio de sesión que usa unha clave SSH a través dunha VPN non significa que a clave privada se entregase ao operador da rede, e esa tranquilidade é máis estreita do que a xente escoita. A autenticación de clave pública envía unha clave pública e unha sinatura que o cliente produce localmente. O reenvío de axente é unha disposición distinta cunha exposición distinta, e pode deixar unha capacidade de autenticación utilizábel nunha máquina que vostede non controla. A resposta que debe depende de cal das dúas cousas ocorreu realmente.

Que envía a autenticación de clave pública

No método estándar de clave pública o cliente ofrece unha clave pública, o servidor decide se acepta esa clave, e o cliente asina un desafío coa clave privada, que permanece no seu ficheiro ou no seu axente. O que cruza a rede é a clave pública e a sinatura resultante. Nada nese intercambio esixe que o servidor, o túnel ou calquera na ruta posúa o material privado.

A especificación de autenticación define esa proba, e a clave privada non é un campo da solicitude.

Iso é unha afirmación sobre un protocolo, non unha referencia de carácter para cada extremo implicado. A comprobación da identidade do host aínda ten que estar intacta, porque un servidor que non pode demostrar quen é pode estar recollendo sinaturas para un propósito que vostede non pretendía. Unha VM alugada, un bastión herdado e un portátil cunha extensión descoñecida son tres preguntas de confianza separadas. Mantéñaas separadas da criptográfica, que está realmente resolvida.

Que delega o reenvío de axente

O reenvío de axente abre unha canle desde o host remoto de volta ao axente da súa máquina, de modo que os procesos dese host poden pedirlle ao axente que asine sen posuír nunca a clave privada. A clave queda onde está, e a capacidade non. Calquera cousa que poida alcanzar ese socket reenviado no host remoto, durante a vida da sesión, pode solicitar operacións de autenticación como unha das identidades cargadas. Iso é autoridade delegada, e por iso o reenvío merece unha política máis estreita que entregar unha clave pública.

Un ficheiro de clave copiado é unha divulgación. Un axente reenviado é un permiso, e os dous necesitan respostas distintas.

Active o reenvío para unha necesidade nomeada e uns hosts nomeados, e comprobe que fai realmente o cliente en lugar do que o ficheiro de configuración parece dicir. Importan os axustes efectivos, porque un bloque de host substitúe silenciosamente un valor global predeterminado. O mesmo razoamento se aplica no lado do servidor, que pode rexeitar o reenvío por completo cando o despregamento nunca o necesita.

Lea as probas antes de escoller unha resposta

Se se cre que un ficheiro de clave privada ou unha identidade de sinatura equivalente quedou exposta, a resposta é a substitución e a revogación mediante o proceso da súa organización, ademais de retirar a súa aceptación de cada servizo que confiaba nel. Borrar unha copia local non invalida as copias que non pode ver.

Se a preocupación é un acceso temporal do axente, a resposta é máis estreita: deteña a delegación innecesaria, revise as sesións e identidades implicadas, e deixe que o responsable do incidente decida se a substitución está xustificada. As probas importan aquí, porque a ausencia dunha exportación observada non demostra que non se fixese un uso indebido da autenticación, e un cambio de ruta por si só non é un diagnóstico dunha clave roubada. Anote que compoñente era de confianza, se o reenvío estaba activado e que se observou realmente. Despois escolla a resposta que encaixe con ese rexistro en lugar da máis dramática dispoñíbel.

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

Execúteos antes e despois dun cambio para que a comparación signifique algo. Unha sesión establecida antes conserva a delegación que se lle concedeu, diga o que diga a configuración agora.

Dous controis que non son intercambiábeis

Protexer o material privado, limitar quen pode pedir que o asine e verificar a identidade da outra parte son tres controis relacionados, e ningún substitúe a outro. Un equipo que retira o reenvío sen comprobar as claves de host arranxou medio problema. Un equipo que rota unha clave porque a ruta cambiou non arranxou nada.

Un extremo comprometido é unha cuarta pregunta, porque o software privilexiado na súa propia máquina pode facer bastante máis que observar paquetes.

Clasifique o incidente nesas categorías antes de tocar nada, e dea a cada unha un responsable. Manteña un rexistro breve do que era de confianza, do que se delegou e do que se verificou, porque ese rexistro é o que fai barata a seguinte revisión en lugar doutro debate. Se algunha categoría é descoñecida, escriba descoñecida en lugar de supor o caso benigno. A distinción é práctica, non académica: decide se substitúe unha credencial, revoga unha sesión ou simplemente deixa de reenviar.