Chiave SSH copiata o agente inoltrato? Due rischi diversi

Un accesso che usa una chiave SSH tramite una VPN non significa che la chiave privata sia stata consegnata all'operatore della rete, e quella rassicurazione è più stretta di quanto la gente senta. L'autenticazione a chiave pubblica invia una chiave pubblica e una firma che il client produce localmente. L'inoltro dell'agente è una disposizione diversa con un'esposizione diversa, e può lasciare una capacità di autenticazione utilizzabile su una macchina che non controllate. La risposta che dovete dipende da quale delle due cose si è verificata davvero.

Cosa invia l'autenticazione a chiave pubblica

Nel metodo standard a chiave pubblica il client offre una chiave pubblica, il server decide se accetta quella chiave, e il client firma una sfida con la chiave privata, che resta nel suo file o nel suo agente. Ciò che attraversa la rete è la chiave pubblica e la firma che ne risulta. Nulla in quello scambio richiede che il server, il tunnel o chiunque lungo il percorso detenga il materiale privato.

La specifica di autenticazione definisce quella prova, e la chiave privata non è un campo della richiesta.

Questa è un'affermazione su un protocollo, non una referenza caratteriale per ogni endpoint coinvolto. Il controllo dell'identità dell'host deve restare intatto, perché un server che non può dimostrare chi è potrebbe raccogliere firme per uno scopo che non avevate previsto. Una VM affittata, un bastione ereditato e un portatile con un'estensione sconosciuta sono tre domande di fiducia separate. Tenetele separate da quella crittografica, che è davvero risolta.

Cosa delega l'inoltro dell'agente

L'inoltro dell'agente apre un canale dall'host remoto verso l'agente sulla vostra macchina, così i processi su quell'host possono chiedere all'agente di firmare senza mai detenere la chiave privata. La chiave resta dov'è, e la capacità no. Qualunque cosa possa raggiungere quel socket inoltrato sull'host remoto, per la durata della sessione, può richiedere operazioni di autenticazione come una delle identità caricate. È un'autorità delegata, ed è per questo che l'inoltro merita una politica più stretta della consegna di una chiave pubblica.

Un file di chiave copiato è una divulgazione. Un agente inoltrato è un permesso, e i due richiedono risposte diverse.

Attivate l'inoltro per un'esigenza nominata e host nominati, e verificate cosa fa realmente il client invece di ciò che la configurazione sembra dire. Contano le impostazioni effettive, perché un blocco host sovrascrive silenziosamente un valore globale predefinito. Lo stesso ragionamento vale sul lato server, che può rifiutare del tutto l'inoltro quando la distribuzione non ne ha mai bisogno.

Leggete le prove prima di scegliere una risposta

Se si ritiene che un file di chiave privata o un'identità di firma equivalente sia stato esposto, la risposta è la sostituzione e la revoca tramite il processo della vostra organizzazione, oltre alla rimozione della sua accettazione da ogni servizio che si fidava di essa. Cancellare una copia locale non invalida le copie che non vedete.

Se la preoccupazione è un accesso temporaneo dell'agente, la risposta è più stretta: fermate la delega non necessaria, riesaminate le sessioni e le identità coinvolte, e lasciate che il responsabile dell'incidente decida se la sostituzione è giustificata. Le prove contano qui, perché l'assenza di un'esportazione osservata non dimostra che nessuna autenticazione sia stata abusata, e un cambio di percorso da solo non è una diagnosi di chiave rubata. Annotate quale componente era considerato fidato, se l'inoltro era attivo e cosa è stato realmente osservato. Poi scegliete la risposta che si adatta a quel verbale invece della più drammatica disponibile.

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

Eseguiteli prima e dopo una modifica perché il confronto significhi qualcosa. Una sessione stabilita prima conserva la delega che le è stata concessa, qualunque cosa dicano ora le impostazioni.

Due controlli che non sono intercambiabili

Proteggere il materiale privato, limitare chi può chiederne la firma e verificare l'identità della controparte sono tre controlli correlati, e nessuno sostituisce l'altro. Un team che rimuove l'inoltro senza controllare le chiavi degli host ha risolto metà di un problema. Un team che ruota una chiave perché il percorso è cambiato non ha risolto nulla.

Un endpoint compromesso è una quarta domanda, perché il software privilegiato sulla vostra macchina può fare molto più che osservare i pacchetti.

Classificate l'incidente in quelle categorie prima di toccare qualsiasi cosa, e date a ciascuna un responsabile. Tenete un breve verbale di ciò che era considerato fidato, di ciò che è stato delegato e di ciò che è stato verificato, perché quel verbale è ciò che rende economica la revisione successiva invece di un altro dibattito. Se una categoria è sconosciuta, scrivete sconosciuta invece di presumere il caso benigno. La distinzione è pratica, non accademica: decide se sostituite una credenziale, revocate una sessione o semplicemente smettete di inoltrare.