Inoltro dell'agente SSH o copia di una chiave: cosa sfugge davvero
L'accesso con chiave pubblica invia una firma, non la chiave privata. L'inoltro dell'agente dà comunque a un altro host la capacità di firmare, che è un'esposizione separata.
Due eventi diversi vengono chiamati chiave SSH compromessa, e richiedono risposte diverse. L'autenticazione con chiave pubblica invia una chiave pubblica e una firma prodotta con la chiave privata, quindi la chiave privata non è mai un campo della richiesta. L'inoltro dell'agente espone altro, perché un host remoto che raggiunge il vostro agente inoltrato può chiedergli di firmare senza mai detenere la chiave. Trattare i due come un solo evento porta o a una rotazione inutile o a una delega che resta attiva.
L'accesso con chiave pubblica trasmette una firma, non la chiave
Lo scambio di autenticazione porta la chiave pubblica dell'utente e una firma sui dati di sessione. Il server verifica quella firma con la chiave di cui si fida già, per questo la metà privata può restare sul client attraverso una rete non fidata. Un operatore VPN che osserva il tunnel vede comunque una sessione SSH cifrata.
Questo descrive il protocollo, non l'affidabilità di ogni estremità del percorso. Mantenete intatto il controllo dell'identità dell'host, perché un client che accetta qualsiasi chiave di host ha abbandonato un controllo diverso da quello di cui parliamo. Una sessione catturata e una chiave catturata sono riscontri separati, e solo uno dei due è una perdita di credenziali. Tenete entrambi in frasi separate del rapporto.
ssh-keygen -lf ~/.ssh/id_ed25519.pub ssh -o StrictHostKeyChecking=yes [email protected]
Il primo comando stampa l'impronta pubblica così potete confrontarla con quella elencata dal server. Il secondo rende esplicito il controllo della chiave dell'host invece di affidarsi a un valore predefinito che nessuno ha letto. Eseguite entrambi prima di cambiare qualcosa sulle chiavi, perché la linea di base sia documentata.
Inoltrare un agente delega la capacità di firmare
Con l'inoltro attivo, sull'host remoto compare un socket e l'agente locale risponde alle richieste che arrivano attraverso di esso. Chiunque possa usare quel socket durante la sessione può autenticarsi come voi verso host che accettano le identità caricate. Nessuna chiave privata attraversa la rete per farlo funzionare.
L'esposizione è la capacità, non il file. Per questo l'inoltro appartiene a un compito nominato e a un host nominato, non a ogni connessione che un portatile apre. Un host di salto che inoltra la connessione senza agente inoltrato di solito elimina del tutto la necessità.
ssh-add -l ssh -o ForwardAgent=no [email protected] ssh -J [email protected] [email protected]
Il primo elenca quali identità l'agente detiene ora, cosa che vale la pena sapere prima di consegnare il suo socket a un'altra macchina. Il secondo si connette senza delega. Il terzo mostra lo schema dell'host di salto che spesso sostituisce l'inoltro del tutto.
Scegliete la risposta in base alle prove che avete
Un'identità di firma che si ritiene esposta richiede il processo di sostituzione e revoca, e la rimozione della sua accettazione dai servizi che si fidavano di essa. Cancellare la copia sul portatile lascia intatte tutte le altre copie. Partite dai servizi, poi ripulite i client.
Un problema temporaneo di delega è più stretto. Terminate l'inoltro che non serviva, e riesaminate con il responsabile dell'incidente quali sessioni e identità copriva. La sostituzione della chiave può seguire, ma lo decidono le prove, non la preoccupazione.
Nessuna esportazione osservata dimostra solo che il meccanismo che temevate non si è verificato. Non dice nulla su cos'altro avrebbe potuto fare un host all'altro capo di quel socket.
Tenete i controlli distinti nel rapporto
Proteggete il materiale privato, limitate chi può chiedergli di firmare, mantenete verificata l'identità della controparte. Sono tre controlli che si rafforzano a vicenda, e nessuno sostituisce l'altro quando spiegate cosa è successo.
Un portatile compromesso o un'applicazione privilegiata su di esso è un terzo caso, con un raggio d'impatto molto più ampio. Cambiare la rotta VPN non lo risolve e non ripristina la fiducia in una chiave che potrebbe essere stata letta dal disco.
Annotate quale componente era fidato, se l'inoltro era attivo e cosa è stato realmente osservato. È quel verbale che rende difendibile la decisione successiva, invece di una congettura su cosa significhi una fuga.