Una passphrase della chiave SSH protegge il file, non la rotta

Un disco di backup di un vecchio portatile contiene ancora una chiave privata SSH, e qualcuno chiede se la VPN la protegge. Non lo fa, e non lo ha mai fatto. La VPN protegge un percorso tra due reti; la passphrase protegge il file; l’agente protegge una sessione in corso. Tre meccanismi diversi, tre modi di fallire diversi, e una copia rubata si preoccupa solo dei primi due.

La passphrase appartiene al file

Una passphrase di chiave SSH cifra il materiale della chiave privata a riposo. Non è la password dell’account inviata al server, e non è la credenziale usata per unirsi alla VPN. Confonderle porta a modifiche che non affrontano l’esposizione.

Il manuale di ssh-keygen di OpenSSH tratta la gestione delle passphrase, incluso l’interruttore -p che imposta una nuova passphrase su una chiave già esistente.

Per una chiave esistente la forma del comando è semplice, e riscrive il file:

ssh-keygen -p -f ~/.ssh/id_ed25519

Usate il processo di manutenzione e ripristino approvato dal proprietario della chiave, perché questa è una scrittura, non un’ispezione. Non pubblicate il file privato e non mettete una passphrase reale su una riga di comando condivisa. Cambiare la passphrase non ricifra una copia presa in precedenza. Annotate la posizione della vecchia copia nel ticket perché il proprietario decida se distruggerla.

Una copia sopravvive al portatile e al tunnel

Una volta copiato un file di chiave, la connessione VPN attiva del portatile non dice più nulla su di esso. Ciò che conta è quanto bene è protetto il file stesso, e quali server si fidano ancora della chiave pubblica corrispondente.

Cambiare la passphrase del file attuale non tocca la copia, e non rimuove la stessa chiave pubblica da authorized_keys su un server. Revoca e ricifratura sono azioni separate.

Trattate quindi una chiave privata divulgata come un evento di identità, non di rete. Rimuovete o sostituite la chiave accettata tramite i server e il processo di registrazione che la possiedono. Fermare la VPN limita una rotta in un dato momento; non è una revoca.

Lo sblocco sposta il segreto in un agente

Un agente conserva identità decifrate per autenticazioni successive, così l’utente non ridigita la passphrase a ogni connessione. È una comodità con un proprio confine di sicurezza.

ssh-agent può limitare per quanto tempo un’identità resta caricata tramite la sua opzione -t, e un’impostazione per singola identità può superare quel limite. Scegliete la politica per l’agente che eseguite davvero invece di supporre che disconnettere la VPN dimentichi ogni chiave caricata.

Un processo compromesso dopo lo sblocco della chiave è un problema diverso da un file cifrato rubato. Inoltrare l’agente a un altro host delega la capacità di autenticazione senza copiare il file della chiave, quindi attivatelo solo per un’esigenza approvata.

Elencate ciò che l’agente tiene attualmente prima e dopo una modifica:

ssh-add -l

I lavori senza supervisione hanno bisogno del proprio piano

Un’attività pianificata non può rispondere a un prompt. Le serve un accordo approvato per le credenziali macchina, e tenere il segreto di sblocco nella stessa directory della chiave, leggibile dallo stesso account, non crea un secondo confine.

Collaborate con il titolare del servizio su una consegna dei segreti supportata o su un funzionamento con hardware, e coprite rinnovo, guasto e ripristino. Volere una persona alla tastiera cambia l’aspetto del guasto rispetto a un host che si avvia senza nessuno che guardi.

Mantenete anche il controllo dell’identità dell’host sul server e le sue restrizioni di account. Una rotta VPN vi dà un percorso privato; non dimostra che ogni ascoltatore SSH raggiungibile sia l’host che intendevate. Registrate l’ascoltatore e l’impronta della chiave dell’host nello stesso inventario della chiave stessa.

Verificate i confini separatamente

Provate ogni confine con la sua domanda. Il file si apre senza la passphrase? L’agente conserva ancora l’identità dopo una disconnessione? Il server accetta ancora la chiave pubblica?

Due comandi rispondono alla prima e alla terza:

ssh-keygen -y -f ~/.ssh/id_ed25519
ssh -v [email protected]

Registrate la protezione del file, l’uso consentito della chiave e la rimozione lato server come tre voci separate. Un tunnel, una passphrase e un agente custodiscono ciascuno una parte diversa della relazione, e solo uno di essi riguarda la rete.