Clau SSH copiada o agent reenviat? Dos riscos diferents

Un inici de sessió que utilitza una clau SSH a través d'una VPN no vol dir que la clau privada s'hagi lliurat a l'operador de la xarxa, i aquesta tranquil·litat és més estreta del que la gent sent. L'autenticació de clau pública envia una clau pública i una signatura que el client produeix localment. El reenviament d'agent és una disposició diferent amb una exposició diferent, i pot deixar una capacitat d'autenticació utilitzable en una màquina que no controleu. La resposta que deveu depèn de quina de les dues coses ha passat realment.

Què envia l'autenticació de clau pública

En el mètode estàndard de clau pública el client ofereix una clau pública, el servidor decideix si accepta aquesta clau, i el client signa un repte amb la clau privada, que es queda al seu fitxer o al seu agent. El que travessa la xarxa és la clau pública i la signatura resultant. Res en aquest intercanvi no exigeix que el servidor, el túnel o qualsevol persona al llarg del camí tingui el material privat.

L'especificació d'autenticació defineix aquesta prova, i la clau privada no és un camp de la sol·licitud.

Això és una afirmació sobre un protocol, no una referència de caràcter per a cada extrem implicat. La comprovació de la identitat de l'amfitrió encara ha d'estar intacta, perquè un servidor que no pot demostrar qui és pot estar recollint signatures per a una finalitat que no preteníeu. Una VM llogada, un bastió heretat i un portàtil amb una extensió desconeguda són tres preguntes de confiança separades. Manteniu-les separades de la criptogràfica, que està genuïnament resolta.

Què delega el reenviament d'agent

El reenviament d'agent obre un canal des de l'amfitrió remot cap a l'agent de la vostra màquina, de manera que els processos d'aquell amfitrió poden demanar a l'agent que signi sense tenir mai la clau privada. La clau es queda on és, i la capacitat no. Qualsevol cosa que pugui arribar a aquest sòcol reenviat a l'amfitrió remot, durant la vida de la sessió, pot sol·licitar operacions d'autenticació com una de les identitats carregades. Això és autoritat delegada, i per això el reenviament mereix una política més estreta que lliurar una clau pública.

Un fitxer de clau copiat és una divulgació. Un agent reenviat és un permís, i els dos necessiten respostes diferents.

Activeu el reenviament per a una necessitat nomenada i uns amfitrions nomenats, i comproveu què fa realment el client en lloc del que la configuració sembla dir. El que importa són els paràmetres efectius, perquè un bloc d'amfitrió substitueix silenciosament un valor global per defecte. El mateix raonament s'aplica a la banda del servidor, que pot rebutjar completament el reenviament quan el desplegament no el necessita mai.

Llegiu les proves abans de triar una resposta

Si es creu que un fitxer de clau privada o una identitat de signatura equivalent ha quedat exposat, la resposta és la substitució i la revocació mitjançant el procés de la vostra organització, a més de treure'n l'acceptació de cada servei que hi confiava. Esborrar una còpia local no invalida les còpies que no veieu.

Si la preocupació és un accés temporal de l'agent, la resposta és més estreta: atureu la delegació innecessària, reviseu les sessions i identitats implicades, i deixeu que el propietari de l'incident decideixi si la substitució està justificada. Les proves hi importen, perquè l'absència d'una exportació observada no demostra que no s'hagi fet mal ús de cap autenticació, i un canvi de camí per si sol no és un diagnòstic d'una clau robada. Anoteu quina peça era de confiança, si el reenviament estava activat i què s'ha observat realment. Després trieu la resposta que encaixi amb aquest registre en lloc de la més dramàtica disponible.

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

Executeu-los abans i després d'un canvi perquè la comparació signifiqui alguna cosa. Una sessió establerta abans conserva la delegació que se li va concedir, digui què digui la configuració ara.

Dos controls que no són intercanviables

Protegir el material privat, limitar qui pot demanar-li que signi i verificar la identitat de l'altra part són tres controls relacionats, i cap no substitueix l'altre. Un equip que treu el reenviament sense comprovar les claus d'amfitrió ha arreglat mig problema. Un equip que canvia una clau perquè la ruta ha canviat no n'ha arreglat cap.

Un extrem compromès és una quarta pregunta, perquè el programari privilegiat a la vostra pròpia màquina pot fer molt més que observar paquets.

Classifiqueu l'incident en aquestes categories abans de tocar res, i doneu a cadascuna un propietari. Manteniu un registre breu del que era de confiança, del que es va delegar i del que es va verificar, perquè aquest registre és el que fa que la propera revisió sigui barata en lloc d'un altre debat. Si alguna categoria és desconeguda, escriviu desconeguda en lloc de suposar el cas benigne. La distinció és pràctica, no acadèmica: decideix si substituïu una credencial, revoqueu una sessió o simplement pareu el reenviament.