WireGuard user authentication

Each side of the tunnel has its own generated key and derived public key (defined as "peer" on the other side of the connection). To act as you are writing, you would need to share the private key between the "clients", which is the worst you can do (technically you can, but I hope nobody would even think about that).

Let's think about "client vs. server" roles:

server

• owns secret key
• has list of all possible peers / users
• each client is represented by own peer definition on the server side with the relevant public key of the client

client

• owns secret key
• one peer definition with the public key of the server

We can say that the client is authenticated using one factor authentication and the authentication is realized using the public key of the client.

• Granting access to a new client means to add a peer definition to the server side (can be realized without restarting VPN / without breaking all current VPN sessions).
• Revoking access for the current client means removing the peer definition on the server side (again, it can be done also without restarting VPN - closing all current sessions).

If I correctly understood your question this "feature" is present in WireGuard out of the box without any needs of extensions.

As @Kamil says, WireGuard's concept is a bit different than other VPN solutions. I also started using it not a long time ago, and if you want to implement something that uses existing authentication, you can get it the way that I've seen in some projects:

• Authenticate your users with your preferred method, plus 2FA, whatever you want.
• After the user is authenticated, the client generates a temporary key pair.
• Through a secure connection, client sends the public key to the server, fetches their config (endpoint, server public key, etc...)
• The client connects to the VPN
• When the user logs out or the session expires, the server can remove the peer from the WireGuard endpoint.

All of this of course can be automated on the client and server side.

To expand upon @Securez's suggestion, what about combining something like SSH with Wireguard? The idea here would be that SSH provides the desired "authentication" service, while Wireguard provides the secure tunnel once a peer successfully authenticates.

For example (on a linux box),

• configure SSH to enable multiple authentication methods, e.g.

  AuthenticationMethods "publickey,keyboard-interactive"

• next, implement a combination of public key + password + TOTP authentication for SSH using something like oathtool (this could also include LDAP based authentication or any combination of the several authentication methods supported by SSH, but for sure include key based authentication)

• then configure /etc/ssh/sshrc to call a script that, based on the user logging into SSH, adds a peer to Wireguard (optionally also opens the WG port for the user's IP address on a firewall e.g. iptables)

User then connects as follows (can be automated using a simple script):

1. SSH to the remote peer
2. upon successful authentication, activate the Wireguard connection

A cron job can be scheduled to check the time elapsed since the latest handshake for each active peer, and if the time is greater than a specified interval, e.g. 180 seconds (meaning peer is no longer connected), kick the peer (and if applicable, close the firewall port).

If you don't need the connecting user to be able to SSH into the remote peer, you can set the user shell to /sbin/nologin. Also, in order for the script called in /etc/ssh/sshrc to be able to add a peer to Wireguard, the script will need sudo access. That risk can be limited with something like the following in /etc/sudoers:

%wireguard-users ALL=NOPASSWD: /path/to/add-wg-peer

where wireguard-users is a group that you would add all the Wireguard users to. Ideally, the add-wg-peer script should not accept any parameters, to limit misuse.

Benefits of such a setup:

• Use of well tested, established, off the shelf components
• A combination of public key + password + TOTP satisfies the requirements of a. something you know, and b. something you have which can mitigate the risk of a compromised peer gaining unauthorized access
• If the firewall functionality is implemented, the attack surface is further reduced by limiting Wireguard access to authorized IP addresses (and also potentially address the "Roaming Mischief" issue identified as a Known Limitation in Wireguard)

Down side:

• You just exposed SSH to the public Internet :o
• Everything else not covered here

Thoughts, observations, criticisms? I'm really interested in hearing what potential pitfalls a setup like this could result in.