Reenviament de l'agent SSH enfront de copiar una clau: què s'exposa realment

Dos esdeveniments diferents reben el nom de clau SSH filtrada, i demanen respostes diferents. L'autenticació amb clau pública envia una clau pública i una signatura feta amb la clau privada, així que la clau privada no és mai un camp de la petició. El reenviament de l'agent exposa una altra cosa, perquè un amfitrió remot que pugui arribar al vostre agent reenviat pot demanar-li que signi sense tenir mai la clau. Tractar-ho com un sol esdeveniment porta o bé a una rotació inútil o bé a una delegació que continua activa.

L'inici de sessió amb clau pública transmet una signatura, no la clau

L'intercanvi d'autenticació porta la clau pública de l'usuari i una signatura sobre les dades de la sessió. El servidor comprova aquesta signatura amb la clau en què ja confia, i per això la meitat privada pot quedar-se al client a través d'una xarxa no confiable. Un operador de VPN que mira el túnel veu una sessió SSH xifrada en qualsevol cas.

Això descriu el protocol, no la fiabilitat de cada extrem del camí. Manteniu intacta la verificació d'identitat de l'amfitrió, perquè un client que accepta qualsevol clau d'amfitrió ha abandonat un control diferent del que discutim. Una sessió capturada i una clau capturada són troballes separades, i només una d'elles és una pèrdua de credencials. Manteniu les dues en frases separades de l'informe.

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

La primera ordre imprimeix l'empremta pública perquè la compareu amb la que el servidor llista. La segona fa explícita la comprovació de la clau de l'amfitrió en lloc de confiar en un valor per defecte que ningú no ha llegit. Executeu les dues abans de canviar res de les claus, perquè la línia de base quedi documentada.

Reenviar un agent delega la capacitat de signar

Amb el reenviament activat, apareix un sòcol a l'amfitrió remot i l'agent local respon les peticions que hi arriben. Qualsevol que pugui usar aquest sòcol durant la sessió pot autenticar-se com a vós davant d'amfitrions que acceptin les identitats carregades. Cap clau privada no travessa la xarxa per fer-ho funcionar.

La capacitat és l'exposició, no el fitxer. Per això el reenviament pertany a una tasca concreta i a un amfitrió concret, i no a cada connexió que fa un portàtil. Un amfitrió de salt que retransmet la connexió sense agent reenviat normalment elimina del tot la necessitat.

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

La primera llista quines identitats té l'agent en aquest moment, cosa que val la pena saber abans de lliurar el seu sòcol a una altra màquina. La segona es connecta sense delegació. La tercera mostra el patró d'amfitrió de salt que sovint substitueix el reenviament del tot.

Trieu la resposta segons les proves que tingueu

Una identitat de signatura que es creu exposada demana el procés de substitució i revocació, i treure'n l'acceptació dels serveis que hi confiaven. Esborrar la còpia del portàtil deixa totes les altres còpies intactes. Comenceu pels serveis i després netegeu els clients.

Un problema temporal de delegació és més estret. Atureu el reenviament que no calia i reviseu amb qui posseeix l'incident quines sessions i identitats cobria. La substitució de la clau pot seguir, però ho decideixen les proves i no la preocupació.

No haver observat cap exportació només demostra que el mecanisme que temíeu no va aparèixer. No diu res sobre què més podia haver fet un amfitrió a l'altre extrem d'aquell sòcol.

Manteniu els controls separats a l'informe

Protegiu el material privat, limiteu qui pot demanar-li que signi, manteniu verificada la identitat de l'altra part. Són tres controls que es reforcen mútuament, i cap d'ells no substitueix l'altre quan expliqueu què va passar.

Un portàtil compromès o una aplicació privilegiada que s'hi executi és un tercer cas amb un abast molt més ampli. Canviar la ruta de VPN no ho resol i no restaura la confiança en una clau que potser s'ha llegit del disc.

Anoteu quin component era de confiança, si el reenviament estava activat i què es va observar realment. Aquest registre és el que fa defensable la decisió següent, en lloc d'una conjectura sobre què significa una filtració.