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.
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)
/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):
- SSH to the remote peer
- 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
%wireguard-users ALL=NOPASSWD: /path/to/add-wg-peer
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)
- 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.