Support asking for passwords again
Opened this issue · 7 comments
Describe the bug
With MFA on the client side, it seems that OpenVPN only asks for a password once. If that fails, it just accepts that the authentication is invalid and doesn't ask again. Would it be possible to support sending a signal or some other mechanism to have a running instance ask for a password again?
To Reproduce
Have an MFA setup. I'm using a systemd-launched instance on the client side. It uses systemd's password authentication mechanism. I have a PR (#649) to remove the timeout, but even without it, if I get it wrong (e.g., enter a code just as it is invalidated or make a typo), I am never asked for the password again. It'd be nice if it would do so after a timeout (just like it does after the system comes back from being suspended and reconnecting) or I could send it a signal to prompt for authentication again.
Expected behavior
When asking for authentication information, ask again if something goes wrong.
Version information (please complete the following information):
- OS: Fedora 40
- OpenVPN version: OpenVPN 2.6.12 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
- Repeat for peer if relevant
Oh, I see that openvpn exits if the auth fails…maybe I can get systemd to restart it in that case… Perhaps a dedicated exit code could be used? Meh, systemd just sees non-zero versus zero for regular exits.
--auth-retry interact might help.
I have that in the client configuration file already. Here's the non-cert bits of the configuration file in use (some configuration fields anonymized):
dev tun
persist-tun
persist-key
data-ciphers CIPHER_LIST
data-ciphers-fallback CIPHER_LIST
keepalive 10 120
cipher CIPHER
auth AUTH_ALGO
tls-client
client
resolv-retry infinite
remote SERVER_HOSTNAME SERVER_PORT udp4
auth-user-pass
auth-retry interact
nobind
verify-x509-name "SERVER_HOSTNAME" name
remote-cert-tls server
explicit-exit-notify
reneg-sec 0
push-peer-info
Could you post the client log? If the server sends AUTH_FAIL on MFA mismatch, the client should start over with another round of user name and password prompt. That's what auth-retry interact is supposed to do.
Here are the logs around an MFA failure:
Dec 05 11:59:43 farprobe openvpn[256417]: 2024-12-05 11:59:43 AUTH: Received control message: AUTH_FAILED
Dec 05 11:59:43 farprobe openvpn[256417]: 2024-12-05 11:59:43 SIGUSR1[soft,auth-failure] received, process restarting
Dec 05 12:00:29 farprobe openvpn[258898]: Failed to query password: Timer expired
Dec 05 12:00:29 farprobe openvpn[256417]: 2024-12-05 12:00:29 ERROR: Failed retrieving username or password
Dec 05 12:00:29 farprobe openvpn[256417]: 2024-12-05 12:00:29 Exiting due to fatal error
Dec 05 12:00:29 farprobe systemd[1]: openvpn@kitware-vpn.service: Main process exited, code=exited, status=1/FAILURE
Dec 05 12:00:29 farprobe systemd[1]: openvpn@kitware-vpn.service: Failed with result 'exit-code'.
Dec 05 12:00:29 farprobe systemd[1]: openvpn@kitware-vpn.service: Consumed 1.576s CPU time.
This might just be a conflation of the timeout issue that #649 is aiming to solve.
Indeed, this is not actually an auth fail, just an expired password query (which is considered a "user does not want to proceed" situation by the openvpn core - same thing happens when you just press return at a password prompt in a terminal session).
Ok, thanks. Should I try to plumb some option to --timeout=0 in #649 or is it OK to make it unconditional? I think it might also make sense to pass --id=openvpn:<some-id> to help figure out which instance is asking (in the case of multiple copies), but I'm not sure where to get that from…maybe the path to the configuration file?