OpenVPN is waiting on a systemd password request: answer it?

A message about systemd-tty-ask-password-agent appears in the terminal, and the tunnel is not up. The tempting reading is that the VPN rejected a password and something is now waiting for a correction. It is more accurate to say a service asked systemd for interactive input, and that the request has not been answered. Which service asked, and which secret it wants, are two questions you can settle before typing anything.

Two conditions decide who should answer

The first condition is whether you started this instance deliberately. A request that follows an action you took is yours to answer, and one that appears without a matching action belongs to something else. The second is whether the secret is account authentication or key protection, because those live in different places and travel through different code paths. Both answers are visible in the journal if you look before acting.

When both answers are clear, the decision is simple: answer through the service's own supported prompting path. When either is unclear, the right move is to investigate rather than to type a password into a prompt you cannot attribute.

That is the whole rule, and it is worth stating before the commands. Everything below follows from it.

List the request before you type anything

The agent can enumerate what is pending without answering anything. sudo systemd-tty-ask-password-agent --list prints the outstanding requests, and that output is the evidence you need to connect a prompt to a unit. Read it before supplying a credential, and keep request descriptions out of any public diagnostic paste.

Correlate the listing with the operation you started and with the unit that owns it. If nothing in the list matches your action, the prompt you saw belongs to another service and is not yours to solve. The unit name in the listing is the only reliable link between a prompt and a service.

Do not answer a request you cannot attribute. The cost of waiting is a delay, while the cost of answering the wrong prompt is a credential in the wrong place.

Which secret does the instance actually need?

auth-user-pass concerns account authentication to the VPN service, and without a credential file the documented behaviour is to ask on the console. askpass instead obtains the passphrase that unlocks protected key material, and it does so before the process daemonizes. Those are different secrets with different lifetimes.

The file formats differ too. The account form expects a username line and a password line, while the key-passphrase file reads the first line as its password. Copying a credential-file recipe from the other role usually produces another prompt rather than a solution. A file with the wrong shape is worse than no file, because the failure moves to a place nobody is watching.

Check which directive the instance uses before deciding what to type. The directive name tells you which secret the prompt is for.

What --query does that --list does not

--query processes every pending request on the calling terminal, which is a much wider action than answering one prompt. It is not an OpenVPN selector, and on a busy machine it can answer requests belonging to other units. Watch mode is wider still, because it keeps handling requests as they arrive.

Use the narrowest mechanism that works. For a single service, that service's own prompting workflow is narrower than a global agent, and it keeps the answer attached to the unit that asked.

Turning a one-time request into an unattended global agent because a notice appeared once is how a temporary annoyance becomes a permanent design. The same caution applies to disabling password-notification units across the host.

Decide, then record the choice

For an unattended deployment, agree the credential source, file permissions and renewal schedule with whoever owns the connection. An interactive second factor may need a person or a dedicated service identity. Suppressing the prompt does not produce that authentication, and removing auth-user-pass only breaks a service that needs it.

After the interaction, look at the same instance for its next event and test the private resource. If nothing is pending, return to the instance state instead of starting every OpenVPN unit on the host.