auth-nocache With a Credential File: Does It Help or Hurt?

OpenVPN prints a warning at startup suggesting auth-nocache, and the tempting response is to add the option and watch the line disappear. That advice assumes an interactive login. Once the username and password live in a file, the comparison changes: the option stops protecting the durable copy, and on a client that drops privileges it can break renegotiation later. Two storage models are worth holding apart before you edit a profile.

Two ways to answer the credential prompt

The first model is a human typing credentials into a terminal, or a management GUI holding them for the session. OpenVPN keeps that copy so it can answer the next renegotiation without asking again, which is exactly what the warning is about. Nothing on disk is involved, so the only thing to protect is the process holding the value. Close the client and the copy is gone with it.

The second model is auth-user-pass pointing at a file, where the file is the store and the client reads it when a value is needed. The exposure that matters here is not process memory but the permissions and ownership of that file. The startup warning comes from the directives in the config, not from an inspection of how you supply the password, so it fires in both models and points at neither.

The rest of this comparison follows from that split: memory handling for one model, file handling and process identity for the other.

What auth-nocache actually discards

With an interactive login, --auth-nocache removes the stored copy from memory after it has been used. The cost is a new prompt at each renegotiation interval, because the next round cannot reuse what was discarded.

With a file-backed login the client can read the file again, so the discard is mostly invisible. It becomes visible in the one place people do not expect: after the daemon drops privileges, if the credential file is not readable by the account it now runs as.

Add the option because you understand that trade, not because a warning appeared. An option added to make a log quieter is an option whose effect nobody measured.

Where the file-backed path breaks

A client that starts as root to open the tunnel device and then switches to user and group reads the credential file twice: once before the switch, once at the renegotiation that follows. If the file is mode 600 and owned by root, the second read fails, and the failure surfaces an hour later as an authentication error that looks like a server problem. Check the client log around the renegotiation interval, then check the account and the file together.

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

Both lines matter. The first tells you who can read the file, the second tells you who the running daemon actually is, and a mismatch between them explains a failure that no amount of password retyping will fix.

The practical fixes are unglamorous: move the file to a directory and an owner the daemon's account can read, or keep the privileged read and confirm that your client only reads once. Do not solve it by making the file world-readable.

The case that does want the option

A login carrying a one-time code wants auth-nocache for a different reason. A one-time code is spent by the first authentication, so a cached copy is useless at the next renegotiation and a stale value could even be replayed.

That is a question about the credential type, not about where it is stored. A static password in a protected file has the opposite profile: it must be readable at every renegotiation, and the protection you need is on the file.

Keep those two reasons separate in the profile comments, because the next administrator will otherwise assume the option is there for the reason they would have chosen.

The comparison in one decision

Choose the interactive model when a person is present and freshness matters, and accept the repeated prompt as its cost. Choose the file model when the client runs unattended, and spend the effort on ownership, mode and the privilege drop instead.

Neither model makes a stored password safe on its own, and neither makes the startup warning meaningful.

If the warning is the only reason you opened the profile, record the decision rather than an unexplained option: credentials come from a file readable by the daemon's account, a renegotiation has been seen to succeed, and the OpenVPN 2.6 manual section on renegotiation was read before changing its interval. That note outlasts any single flag.