Stop NetworkManager From Showing a Saved VPN Password
Prompt each time, hand it to a keyring, or keep a root-only file. Each choice carries a different exposure, and the password flag should match it.
NetworkManager can hold a VPN password so the connection comes up without anyone typing it, and it can show that value back through the editor or through nmcli --show-secrets. Three ownership models are available, and the display behaviour is only a symptom of which one you chose. Pick the model first, then set the flag that matches it, rather than hiding a field with a placeholder that will confuse the next person.
Three ownership models
The first model prompts every time. Nothing is stored, the secret exists only for the duration of the activation, and anyone starting the connection has to know the password. It is the least convenient option and the easiest one to defend.
The second hands the secret to a keyring owned by the user. The agent unlocks when the session starts and supplies the value on demand, which keeps it out of the connection file but ties the connection to that user's session. Two conditions follow: the agent has to be running, and it has to be unlocked.
The third stores a protected credential for a system connection. It survives reboots and works before anyone logs in, and in exchange the value sits on disk guarded by file permissions rather than by encryption.
Each model is reasonable in the right context. The mistake is mixing them, which is how a laptop ends up with a secret in two places and no clear answer about which one is authoritative. Write down which model a profile uses. One line in the team runbook saves the next person from inventing a fourth place to look.
Read the current state before changing it
Look at the profile and at the secret state as the user who manages the connection. The second command is the one that tells you whether the value is actually readable.
nmcli connection show "Office VPN"
nmcli --show-secrets connection show "Office VPN"
sudo stat -c '%U %a %n' /etc/NetworkManager/system-connections/*.nmconnectionA keyfile in that directory is normally root-owned with mode 600. That keeps ordinary users out, and it does not keep root out, which matters when the same machine is shared or when a backup runs as root.
File permissions are a boundary, not encryption. Anyone who can read the file as root has the password in clear text. That is an acceptable trade for an unattended server and a poor one for a shared workstation. Writing it down once prevents a long argument about whether the value is protected.
What each flag value does
The VPN secret carries a flags property, and the values are not intuitive from the numbers alone.
| Value | Meaning | Practical effect |
|---|---|---|
| 0 | No special flag | Secret is typically saved with the connection |
| 1 | Agent-owned | A keyring or secret agent supplies it |
| 2 | Not saved | Prompted at each activation |
| 4 | Not required | Connection proceeds without asking |
The effective behaviour also depends on the plugin and on whether an agent is running, so treat the table as the contract and the observed behaviour as the thing you verify. A value that works on one desktop can behave differently on a server with no session. That gap is where most of the confusing tickets live.
Set the property explicitly rather than deleting a line and hoping. An absent flag is not a policy, and the next package update may fill it in with something you did not intend.
Match the model to when the connection starts
If the connection only ever starts while a user is logged in, agent-owned is a good fit and keeps the secret out of the file. If it starts at boot, before any session exists, an agent cannot help you.
That is the whole decision for most machines. It also explains a class of confusing reports where the connection works interactively and fails after a reboot. The flag never changed; the context did.
For the unattended case, a restricted root-owned file or an approved credential source is the practical answer. Keep it out of the connection profile if that profile is ever exported or copied to another machine.
If the value was already visible, rotate it
Altering a flag leaves the password itself untouched. A value that turned up in a screenshot, in shell history, in a bundle sent to support, or in a file other users could open should be considered disclosed.
Change it on the server, then fix the client and terminate any session that authenticated with the old one. Deleting the local connection revokes nothing on the far side, which is the part people miss.
Then stop putting the password on the command line. It lands in shell history and can appear in a process listing; use the interactive prompt or the agent instead.
Verify by reconnecting
Repeat the command that showed the secret and confirm the field is no longer printed. Then disconnect and reconnect, and reboot if the connection starts automatically, because the interesting failure only appears when the session context changes.
If the secret still shows up, another profile or another agent is supplying it. Inspect the active connection and the keyring instead of deleting files until the symptom moves.