Tonight, I was trying to launch my OpenVPN (for various reasons),
but it didn't work, and the server spat this in my
/var/log/openvpn_tcp.log:
AUTH-PAM: BACKGROUND: received command code: 0
AUTH-PAM: BACKGROUND: USER: jvoisin
AUTH-PAM: BACKGROUND: my_conv[0] query='Password: ' style=1
AUTH-PAM: BACKGROUND: user 'jvoisin' failed to authenticate: System error
PLUGIN_CALL: POST /usr/lib/x86_64-linux-gnu/openvpn/plugins/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1
PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/x86_64-linux-gnu/openvpn/plugins/openvpn-plugin-auth-pam.so
TLS Auth Error: Auth Username/Password verification failed for peer
Something went wrong with pam (let alone the fact
that Debian tought that it might be fun to move
/usr/lib/openvpn/openvpn-plugin-auth-pam.so to
/usr/lib/x86_64-linux-gnu/openvpn/plugins/openvpn-plugin-auth-pam.so without
a warning a couple of weeks ago.), and I got this line in my
/var/log/auth.log: PAM audit_log_acct_message() failed: Operation not permitted.
This is due to systemd's capabilities, that are wrongly set in the
/lib/systemd/system/openvpn@.service file, missing the CAP_AUDIT_WRITE one,
so edit it to look like something like this:
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE CAP_AUDIT_WRITE
Restart the systemd daemon with systemctl restart openvpn, and maybe issue a
systemctl daemon-reload before, just in case (yes, I'm a completely legit systemd expert),
and it should work again.
It took me way to long to find the culprit and to fix it, but I guess it's because I know nothing about capabilities, nor about this new fancy init system. Odds are that my next vpn endpoint will be something easier to manager, like alpine.