Var ska Linux lagra ditt VPN-lösenord? Inte i profilen
NetworkManagers hemlighetsflaggor avgör om profilen, en nyckelringsagent eller ingen håller lösenordet. Svaret beror på när anslutningen startar.
VPN-lösenordet måste bo någonstans: i anslutningsprofilen, i en nyckelring som skrivbordet låser upp, eller ingenstans. NetworkManager kallar det valet en hemlighetsflagga, och att välja fel är anledningen till att en anslutning fungerar efter inloggning och misslyckas som tjänst. Flaggan är en rad konfiguration, och den avgör vilket av de tre utfallen du får.
Tre flaggor täcker nästan varje fall, och beslutet handlar om när anslutningen startar.
Tre hemlighetsflaggor, tre beteenden
En flagga på 0 betyder att hemligheten sparas med anslutningen, i vilket lager profilen än ligger. En flagga på 1 gör den agentägd: hemligheten kommer från en hemlighetsagent som en skrivbordsnyckelring, och NetworkManager frågar efter den vid aktivering. En flagga på 2 betyder inte sparad, så hemligheten skrivs aldrig och måste lämnas varje gång. Flagga 4 markerar en hemlighet som inte krävd, för anslutningar som verkligen inte behöver någon.
| 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 |
Sätt flaggorna per hemlighet i stället för per anslutning. En anslutning kan ha ett agentägt lösenord och en sparad lösenfras för privat nyckel.
Bestäm utifrån när anslutningen startar
Om en inloggad användare startar anslutningen är agentägd det förnuftiga standardvalet: nyckelringen låses upp vid inloggningen och hemligheten ligger aldrig i en fil. Om anslutningen måste komma upp innan någon loggar in är agentägd det fel valet, eftersom det finns ingen sessionsnyckelring att låsa upp.
Det är hela beslutet. Allt annat är en variant av det.
För en tjänst före inloggning är ett systemomfattande lager eller en skyddad nyckelfil det stödda mönstret, och filrättigheter blir skyddet. Lös inte problemet genom att klistra in lösenordet i ett skalskript som körs vid start.
Vad nyckelringen ger och vad den inte ger
En nyckelring håller hemligheten utanför anslutningsprofilen och binder den till en användarsession. Den gör inte hemligheten tillgänglig för en tjänst utan session, och den krypterar ingenting på linjen. Det är separata egenskaper som folk ofta blandar ihop. Det den faktiskt köper är en mindre skadadradie när en profilfil läcker.
Den privata nyckel som profilen refererar till behöver egna rättigheter, oavsett var lösenordet bor.
Diagnostik utan att dumpa hemligheter
Anslutningsnamn, UUID:n och flaggor räcker oftast för att förklara ett fel. nmcli connection show listar profilen, och hemlighetsflaggorna talar om var lösenordet skulle komma ifrån.
Undvik --show-secrets i ärenden och chatt. När det väl är inklistrat är det en autentiseringsuppgift i en utskrift.
Lagring är inte återkallelse
Att ta bort en hemlighet från en nyckelring ogiltigförklarar inte den autentiseringsuppgift som fjärroperatören redan har accepterat. Återkallelse av ett konto är en åtgärd på serversidan, och lokal lagring är en separat fråga med en separat ägare.
Bestäm båda före incidenten, inte under den. En interaktiv användaranslutning och en tjänst före inloggning behöver olika svar, och ett delat skalskript är inget av dem. NetworkManagers dokumentation om hemlighetsflaggor listar värdena i sin helhet.