Hvor bør Linux lagre VPN-passordet ditt? Ikke i profilen
NetworkManagers hemmelighetsflagg avgjør om profilen, en nøkkelringagent eller ingen holder passordet. Svaret avhenger av når tilkoblingen starter.
VPN-passordet må bo et sted: i tilkoblingsprofilen, i en nøkkelring som skrivebordet låser opp, eller ingen steder. NetworkManager kaller det valget et hemmelighetsflagg, og det er derfor en tilkobling virker etter pålogging og feiler som tjeneste når man velger det gale. Flagget er én linje konfigurasjon, og det avgjør hvilket av de tre utfallene du får.
Tre flagg dekker nesten alle tilfeller, og beslutningen handler om når tilkoblingen starter.
Tre hemmelighetsflagg, tre atferdsmønstre
Et flagg på 0 betyr at hemmeligheten lagres sammen med tilkoblingen, i hvilket lager profilen enn ligger. Et flagg på 1 gjør den agent-eid: hemmeligheten kommer fra en hemmelighetsagent som en skrivebordsnøkkelring, og NetworkManager spør etter den ved aktivering. Et flagg på 2 betyr ikke lagret, så hemmeligheten skrives aldri og må oppgis hver gang. Flagg 4 markerer en hemmelighet som ikke påkrevd, for tilkoblinger som virkelig ikke trenger noen.
| 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 |
Sett flaggene per hemmelighet i stedet for per tilkobling. Én tilkobling kan ha et agent-eid passord og en lagret privatnøkkelpassfrase.
Bestem ut fra når tilkoblingen starter
Hvis en innlogget bruker starter tilkoblingen, er agent-eid det fornuftige standardvalget: nøkkelringen låses opp ved pålogging, og hemmeligheten ligger aldri i en fil. Hvis tilkoblingen må opp før noen logger inn, er agent-eid det gale valget, fordi det finnes ingen sesjonsnøkkelring å låse opp.
Det er hele beslutningen. Alt annet er en variant av den.
For en tjeneste før pålogging er et systemomfattende lager eller en beskyttet nøkkelfil det støttede mønsteret, og filrettigheter blir beskyttelsen. Ikke løs problemet ved å lime passordet inn i et skallskript som kjører ved oppstart.
Hva nøkkelringen gir, og hva den ikke gir
En nøkkelring holder hemmeligheten utenfor tilkoblingsprofilen og binder den til en brukersesjon. Den gjør ikke hemmeligheten tilgjengelig for en tjeneste uten sesjon, og den krypterer ingenting på linjen. Dette er atskilte egenskaper som folk ofte blander sammen. Det den faktisk kjøper, er en mindre skaderadius når en profilfil lekker.
Den private nøkkelen som profilen refererer til, trenger egne rettigheter, uavhengig av hvor passordet bor.
Diagnostikk uten å dumpe hemmeligheter
Tilkoblingsnavn, UUID-er og flagg er vanligvis nok til å forklare en feil. nmcli connection show lister profilen, og hemmelighetsflaggene forteller deg hvor passordet skulle komme fra.
Unngå --show-secrets i saker og chat. Når det først er limt inn, er det en legitimasjon i en utskrift.
Lagring er ikke tilbakekalling
Å fjerne en hemmelighet fra én nøkkelring gjør ikke legitimasjonen ugyldig som fjernoperatøren allerede har godtatt. Tilbakekalling av en konto er en handling på serversiden, og lokal lagring er en egen sak med en egen eier.
Bestem begge deler før hendelsen, ikke under den. En interaktiv brukertilkobling og en tjeneste før pålogging trenger ulike svar, og et delt skallskript er ingen av delene. NetworkManagers dokumentasjon om hemmelighetsflagg lister verdiene fullt ut.