OpenVPN service stops at Enter Private Key Password: fix it
A service has no terminal, so an encrypted key needs askpass and a readable file. Separate the key passphrase from the server login and check the unit.
OpenVPN asks for the private key passphrase on the local machine, so a working login file never answers it. On a service there is no terminal to type into, and the start either hangs or fails with a journal entry that names the input rather than the cause. Two secrets are involved, and each needs its own readable source before the unit is restarted. The walk below separates them, then checks the identity that actually opens each file.
Tell the two prompts apart
The key passphrase decrypts the local private key; the account credentials authenticate the session to the server. They come from different places, fail at different moments and produce different messages. Confusing them sends people looking for a password reset when the account was never involved. Read the prompt text before changing any option, because the wording is the only reliable clue about which secret is missing.
In Community OpenVPN 2.x, askpass names a file that holds the key passphrase on its first line, and auth-user-pass names a file with the username on one line and the password on the next. Neither file can satisfy the other option. A desktop app or a NetworkManager profile may keep both in its own secret store, which a command-line client never reads, so note which client you are configuring before writing either path.
Point both options at readable files
A profile that needs both inputs ends up with three file references: the encrypted key, the passphrase that unlocks it, and the login pair. Add them without touching the CA or the identity checks, since those decide who the server is and are not part of this problem. If the deployment does not use account credentials at all, adding auth-user-pass creates an input nobody can supply.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authBare options behave differently from options with paths, and the difference matters on a service. An askpass without an argument still reads the console, and an auth-user-pass file holding only a username still leaves a password prompt waiting. Once the client daemonizes it cannot ask a terminal for input at all, so a service configured this way does not come up.
Absolute paths remove the working-directory question but do not grant access. Ownership, mode and traversal come next, and all three are checked against the account the process runs as.
Read the unit's configuration before the profile
The unit, not the file you were editing, decides which configuration the instance loads. Read its command line and any drop-ins, then follow the working directory to the profile that is actually in use. A passphrase reference added to a different .ovpn file changes nothing for this instance.
Three read-only commands answer most of it. The first prints the unit and any drop-ins, the second prints the identity and sandbox settings that bound the process, and the third prints what the last start actually complained about. Use the instance name that exists on the host:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bPay attention to ProtectHome and to the profile's own user, group and chroot options. A file under a home directory can be readable in your shell and invisible inside the service once home directories are hidden. The account systemd starts with is not always the account that ends up opening the key.
Prove that the runtime identity can open both files
Reading the mode is not enough, because every directory on the path has to be traversable by the same identity. Walk the path component by component, then test the open as the account the process uses. A file with mode 600 owned by root works only while the process is still root, which is not true after the privilege drop many profiles perform. Two commands cover the traversal and the open:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableThe first command prints the mode of each component and fails where the account cannot traverse; the second answers the only question that matters, which is whether the runtime identity can open the file for reading. Neither prints file contents, which is the point when the file holds a passphrase. Repeat the test for the login file, because the two are often stored with different ownership.
If the process uses a chroot or a restricted namespace, run the same test from inside that view, or the answer describes the wrong filesystem. A passphrase stored under a hidden home directory is the usual example of a test that passes outside the unit and fails inside it.
Check the first start, then a reconnect
Start the instance once and read the first failure rather than the last. A missing input file, a failed key decryption and a server-side AUTH_FAILED are three different events with three different repairs. Fixing a permissions warning proves nothing about whether the key was unlocked.
The journal line tells you which of the three you have. The repair follows from which input failed:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
Then test the lifecycle you actually need: a boot start and any supported reconnect, not just a manual start from your shell. With auth-nocache the inputs are dropped after the first use, so a later reconnect still needs a readable source. A keyring unlocked at desktop login is not available to a service that started before anyone logged in, which is the usual reason a manual test passes and a reboot fails. If the first start succeeds and a later reconnect fails, read the journal for the reconnect event before changing permissions again.
Storing the passphrase beside the key reduces what the encryption buys you, so restrict that file and its backups. Treat removing the key passphrase as a separate credential decision rather than the repair for a missing input. A deployment that depends on human approval or interactive MFA needs its supported agent or management integration; a permanently saved one-time code is not an equivalent replacement.