Dove dovrebbe conservare Linux la tua password VPN? Non nel profilo
I flag di segreto di NetworkManager decidono se la password la tiene il profilo, un agente del portachiavi o nessuno. La risposta dipende da quando parte la connessione.
La password VPN deve vivere da qualche parte: nel profilo di connessione, in un portachiavi che il desktop sblocca, o da nessuna parte. NetworkManager chiama questa scelta flag di segreto, e scegliere quello sbagliato è il motivo per cui una connessione funziona dopo l’accesso e fallisce come servizio. Il flag è una riga di configurazione, e decide quale di questi tre esiti ottieni.
Tre flag coprono quasi ogni caso, e la decisione riguarda quando parte la connessione.
Tre flag di segreto, tre comportamenti
Un flag 0 significa che il segreto viene salvato con la connessione, in qualsiasi archivio contenga il profilo. Un flag 1 lo rende di proprietà dell’agente: il segreto arriva da un agente di segreti come un portachiavi del desktop, e NetworkManager lo chiede all’attivazione. Un flag 2 significa non salvato, quindi il segreto non viene mai scritto e va fornito ogni volta. Il flag 4 contrassegna un segreto come non richiesto, per connessioni che davvero non ne hanno bisogno.
| Flag | Where it lives | Works unattended |
|---|---|---|
| 0 saved | Connection profile | Yes, if the store is readable |
| 1 agent-owned | Secret agent or keyring | Only if that agent is available |
| 2 not-saved | Nowhere | No |
Imposta i flag per singolo segreto, non per connessione. Una connessione può avere una password di proprietà dell’agente e una passphrase della chiave privata salvata.
Decidi in base a quando parte la connessione
Se un utente già connesso avvia la connessione, la proprietà dell’agente è l’impostazione predefinita sensata: il portachiavi viene sbloccato dall’accesso e il segreto non risiede mai in un file. Se la connessione deve salire prima che qualcuno acceda, la proprietà dell’agente è la scelta sbagliata, perché non c’è alcun portachiavi di sessione da sbloccare.
Questa è tutta la decisione. Tutto il resto è una variante.
Per un servizio prima dell’accesso, il modello supportato è un archivio a livello di sistema o un file di chiave protetto, e i permessi del file diventano la protezione. Non risolvere il problema incollando la password in uno script shell che viene eseguito all’avvio.
Cosa dà il portachiavi e cosa no
Un portachiavi tiene il segreto fuori dal profilo di connessione e lo lega a una sessione utente. Non rende il segreto disponibile a un servizio senza sessione, e non cifra nulla sul collegamento. Sono proprietà separate che le persone spesso fondono. Ciò che compra davvero è un raggio di danno più ridotto quando un file di profilo trapela.
La chiave privata a cui fa riferimento il profilo ha bisogno dei propri permessi, indipendentemente da dove vive la password.
Diagnostica senza riversare segreti
Nomi di connessione, UUID e flag di solito bastano a spiegare un guasto. nmcli connection show elenca il profilo, e i flag di segreto ti dicono da dove doveva arrivare la password.
Evita --show-secrets nei ticket e nelle chat. Una volta incollato, è una credenziale in una trascrizione.
La conservazione non è la revoca
Rimuovere un segreto da un portachiavi non invalida la credenziale che l’operatore remoto ha già accettato. La revoca dell’account è un’azione lato server, e la conservazione locale è una questione separata con un proprietario separato.
Decidi entrambe le cose prima dell’incidente, non durante. Una connessione utente interattiva e un servizio prima dell’accesso richiedono risposte diverse, e uno script shell condiviso non è né l’una né l’altra. La documentazione di NetworkManager sui flag di segreto elenca i valori per intero.