auth-user-pass should execute file if exec bit is set

[ssbarnea]

In order to allow the use of dynamic credentials (OTP/temporary) the auth-user-pass client option should executed the file given as parameter if the file has the exec bits set on it and use the STDOUT output instead of the file content.

This kind of behaviour is common, one example is the HOSTS file on ansible which is executed if is executable or loaded as a classic config file if not.

By doing this, we would be able to have variable credentials in the client.

[novaflash]

What's wrong with making sure the file is updated with the current credentials before you even start the connection?

[David Sommerseth]

No, this is definitely the wrong approach. We do not want openvpn, which may run with elevated privileges, to run more scripts than it already does.

This scenario can anyway be resolved using --management, --management-hold and --management-query-password.

Proof of concept

Run this in terminal 1:

# openvpn --config $CONFIG_FILE --management /run/user/$UID/ovpn unix --management-hold --management-query-password

Run this in terminal 2:

printf "hold release" | nc -U /run/user/$UID/ovpn
sleep 0.5
printf "username USERNAME\npassword PASSWORD" | nc -U /run/user/$UID/ovpn

[ssbarnea]

David, can you please elaborate on how this management interface could ever be used in a headless/non-interactive mode for providing credentials for the ovpn client?

What I see you describing is use of a socker for getting the credentials, which means that soneome would have to run a service (for each user) that would run all the time in order to provide credentials in case they are needed.

I am currently wondering if there is a way to make this work using a crontab entry that starts this magic socket.

[David Sommerseth]

If you are going to run this on a headless/non-interactive mode, wouldn't it make more sense to just use the password file --auth-user-pass already supports? Make that file only readable by the openvpn users, and you have restricted access to whom can access the username/password.

As you anyhow need to have this information available in clear-text for the OpenVPN process, it makes sense to take the path of least resistance and not over-engineer it.

If you have a setup handling with users using username/password and headless/non-interactive systems in parallel, I'd rather recommend using plain certificate based certification for those systems and use username/password for those real users. And there are at least two ways to achieve this; 1) two separate OpenVPN server processes, or 2) Having an auth-script on the server side who accepts certain certificate subject identifiers as not needing the username/password check.

But the quick-fix in your use case is basically providing a filename which contains a username and password (on separate lines) and tell --auth-user-pass about it.

[novaflash]

Having an auth-script on the server side who accepts certain certificate subject identifiers as not needing the username/password check.

I believe this is pretty much what Access Server does with auto-login profiles right now.

[ssbarnea]

First, this ticket is only about client side of openvpn, you can assume that there is no way to control the way the openvpn server authentication is configured. If the server asks for user+variablepass, we need to find a way to configure the client to provide them.

Maybe it would be easier to understand the challenges by reading my almost two years old post ​https://medium.com/@sbarnea/automating-openvpn-login-with-otp-82b58123e0c8 or my attempt to make the pfsense router deal with 2FA issue at ​https://redmine.pfsense.org/issues/8122 -- I even had a patch and PR that worked for more than an year, surviving three upgrades.

The main issue with file based password is that the client config can save the credentials once configuration is updated or when you try to establish connection BUT it will not update the file on reconnects, as this is done solely by openvpn which does not trigger anything that could recreate the file.

For this reason I proposed the approach of executing the file if it has the exec bit on and read its output, this being a common approach taked by many tools that had dynamic configuration (example ansible inventory).

If OpenVPN client would be able to do this, it would work on any client, even if this is a MacOS Viscosity or an embedded router. If not, (power)users are forced to rely on dirty hacks that are likely to fail on upgrades.

[David Sommerseth]

If you do not control the server side, the implementation of enforcing OTP is most likely due to the VPN service provider expecting a user to provide a unique token value for the authentication. If this VPN service is expected to be used in an environment with mixed use cases (users and headless/non-interactive hosts), then this needs to first of all be fixed on the server side.

Certificate based authentication itself is a strong authentication method. Username/password authentication (without or preferably with OTP) and is an alternative method when certificate based authentication is less convenient. The strongest authentication level is by combining them, but that is more used when you want users to have separate access levels depending on the device the connect from.

The approach of +x which causes a configuration file to be executed is a trap filled with security issues as well. And we really do not want to extend more of the OpenVPN code to execute external code. Ansible is very different in this regard, as there you most commonly have admin privileges and can mess up the system anyhow. For OpenVPN, it should not need any particular privileges when handling authentication.

The real alternative for OpenVPN 2.x is already brought up, via the management interface. And the service providing the information can be pre-started, then OpenVPN will need --management-client in the configuration - all documented in the man page.