Where Should Linux Store Your VPN Password? Not in the Profile
NetworkManager secret flags decide whether the profile, a keyring agent or nobody holds the password. The answer depends on when the connection starts.
The VPN password has to live somewhere: in the connection profile, in a keyring the desktop unlocks, or nowhere at all. NetworkManager calls that choice a secret flag, and picking the wrong one is why a connection works after login and fails as a service. The flag is one line of configuration, and it decides which of those three outcomes you get.
Three flags cover almost every case, and the decision is about when the connection starts.
Three secret flags, three behaviours
A flag of 0 means the secret is saved with the connection, in whatever store holds the profile. A flag of 1 makes it agent-owned: the secret comes from a secret agent such as a desktop keyring, and NetworkManager asks for it at activation. A flag of 2 means not-saved, so the secret is never written and must be supplied each time. Flag 4 marks a secret as not required, for connections that genuinely need none.
| 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 |
Set the flags per secret rather than per connection. One connection can have an agent-owned password and a saved private-key passphrase.
Decide by when the connection starts
If a logged-in user starts the connection, agent-owned is the sane default: the keyring is unlocked by the login and the secret never sits in a file. If the connection must come up before anyone logs in, agent-owned is the wrong choice, because there is no session keyring to unlock.
That is the whole decision. Everything else is a variant of it.
For a pre-login service, a system-scoped store or a protected key file is the supported pattern, and file permissions become the protection. Do not solve the prompt by pasting the password into a shell script that runs at boot.
What the keyring gives you and what it does not
A keyring keeps the secret out of the connection profile and ties it to a user session. It does not make the secret available to a service with no session, and it does not encrypt anything on the wire. Those are separate properties people often merge. What it does buy is a smaller blast radius when a profile file leaks.
The private key referenced by the profile needs its own permissions, independently of where the password lives.
Diagnostics without dumping secrets
Connection names, UUIDs and flags are usually enough to explain a failure. nmcli connection show lists the profile, and the secret flags tell you where the password was supposed to come from.
Avoid --show-secrets in tickets and chat. Once it is pasted, it is a credential in a transcript.
Storage is not revocation
Removing a secret from one keyring does not invalidate the credential the remote operator already accepted. Account revocation is a server-side action, and local storage is a separate concern with a separate owner.
Decide both before the incident, not during it. An interactive user connection and a pre-login service need different answers, and a shared shell script is neither. NetworkManager's secret flag documentation lists the values in full.