Dous sucesos distintos reciben o nome de chave SSH filtrada, e esixen respostas diferentes. A autenticación con chave pública envía unha chave pública e unha sinatura feita coa chave privada, así que a chave privada nunca é un campo da petición. O reenvío do axente expón outra cousa, porque un host remoto que alcanza o seu axente reenviado pode pedirlle que asine sen ter xamais a chave. Tratar ambos como un só suceso leva ou ben a unha rotación inútil ou ben a unha delegación que segue activa.

O inicio de sesión con chave pública transmite unha sinatura, non a chave

O intercambio de autenticación leva a chave pública do usuario e unha sinatura sobre os datos da sesión. O servidor comproba esa sinatura coa chave na que xa confía, por iso a metade privada pode quedar no cliente a través dunha rede non fiable. Un operador de VPN que observa o túnel ve unha sesión SSH cifrada en calquera caso.

Iso describe o protocolo, non a fiabilidade de cada extremo do camiño. Manteña intacta a verificación de identidade do host, porque un cliente que acepta calquera chave de host abandonou un control distinto do que tratamos. Unha sesión capturada e unha chave capturada son achados separados, e só un deles é unha perda de credenciais. Manteña ambos en frases separadas do informe.

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh -o StrictHostKeyChecking=yes [email protected]

O primeiro comando imprime a pegada pública para que a compare coa que enumera o servidor. O segundo fai explícita a comprobación da chave do host en lugar de confiar nun valor por defecto que ninguén leu. Execute ambos antes de cambiar nada nas chaves, para que a liña base quede documentada.

Reenviar un axente delega a capacidade de asinar

Co reenvío activado, aparece un socket no host remoto e o axente local responde as peticións que chegan por el. Calquera que poida usar ese socket durante a sesión pode autenticarse como vostede ante hosts que acepten as identidades cargadas. Ningunha chave privada cruza a rede para que iso funcione.

A capacidade é a exposición, non o ficheiro. Por iso o reenvío pertence a unha tarefa concreta e a un host concreto, e non a cada conexión que fai un portátil. Un host de salto que retransmite a conexión sen axente reenviado normalmente elimina a necesidade por completo.

ssh-add -l
ssh -o ForwardAgent=no [email protected]
ssh -J [email protected] [email protected]

O primeiro enumera que identidades ten o axente agora, algo que convén saber antes de entregar o seu socket a outra máquina. O segundo conecta sen delegación. O terceiro mostra o patrón de host de salto que a miúdo substitúe o reenvío por completo.

Escolla a resposta segundo as probas que teña

Unha identidade de sinatura que se cre exposta esixe o proceso de substitución e revocación, e retirar a súa aceptación dos servizos que confiaban nela. Borrar a copia do portátil deixa intactas todas as demais copias. Comece polos servizos e despois limpe os clientes.

Un problema temporal de delegación é máis estreito. Remate o reenvío que non era necesario e revise co responsable do incidente que sesións e identidades cubría. A substitución da chave pode seguir, pero decídena as probas e non a preocupación.

Non ter observado ningunha exportación só demostra que o mecanismo que temía non apareceu. Non di nada sobre que máis podería ter feito un host no outro extremo dese socket.

Manteña os controis separados no informe

Protexa o material privado, limite quen pode pedirlle que asine, manteña verificada a identidade da outra parte. Son tres controis que se reforzan entre si, e ningún substitúe o outro cando explica que ocorreu.

Un portátil comprometido ou unha aplicación privilegiada nel é un terceiro caso cun alcance moito maior. Cambiar a ruta de VPN non o resolve e non restaura a confianza nunha chave que pode terse lido do disco.

Anote que compoñente era de confianza, se o reenvío estaba activado e que se observou realmente. Ese rexistro é o que fai defendible a seguinte decisión en lugar dunha conxectura sobre que significa unha filtración.

Artigos relacionados