I think the question is not, should you use SSH as a makeshift VPN, as that answer is more obviously "probably not". The harder question is, is it better to VPN in before connecting to SSH, and present MFA at the VPN and SFA at the server, or is it better to expose SSH directly and perform full MFA directly at the SSH endpoint?
What do you trust more, OpenVPN with a port forward to an SSH server behind it, or a directly exposed SSH agent? Which will properly authenticate users without exposing any possible auth bypass, RCE, DoS, side channels, or potential vulnerabilities?
In general it's best if you can assume a perimeter firewall (i.e. VPN) will not always succeed in keeping the bad packets out. Of course it's a cop out to simply say "do both".
In general if you are managing a larger number of servers, it's not practical to MFA to each one individually / interactively. So you are forced to MFA to the border, and SFA to the individual servers. If you have a small number of servers you may find you get more fine-grain control, better auditing, and fewer points of failure to do something like this article suggests -- skip the OpenVPN and implement fully server-side validated MFA directly to the server.
The ultra-paranoid would add an HMAC based port-knocking scheme and forget about primitives like fail2ban. This could either be based on a 3rd factor or reusing the existing private key.
Thanks, this was a good answer. Yes, I am going to want to use SSH in the end, the console is typically what I want, potentially with a single port forwarded (8080 or whatnot), so I guess the question really comes down to "is there any reason to believe there are more exploits in OpenSSH than in VPN", and possibly also "is it so hard to configure and keep updated a Linux box with OpenSSH correctly that it is better to go with VPN".
OpenSSH has had critical vulnerabilities in the early 2000's, but it's held up extremely well the last 10 years. OpenVPN has a significantly higher attack surface, especially if you consider things like XSRF on the Admin GUI. You'll almost certainly need a hardened and updated OpenSSH in any case, so using a VPN can only possibly increase your attack surface.
My own opinion is if you have few enough servers and no other reason for a VPN, then expose SSH on a non-standard port or use a port knocker, and use something like this article's MFA solution.
The non-standard port or port knocking is really just to keep spam out of your logs. Since authentication requires a 4096 bit private key, you're not worried about brute force in any case.
What do you trust more, OpenVPN with a port forward to an SSH server behind it, or a directly exposed SSH agent? Which will properly authenticate users without exposing any possible auth bypass, RCE, DoS, side channels, or potential vulnerabilities?
In general it's best if you can assume a perimeter firewall (i.e. VPN) will not always succeed in keeping the bad packets out. Of course it's a cop out to simply say "do both".
In general if you are managing a larger number of servers, it's not practical to MFA to each one individually / interactively. So you are forced to MFA to the border, and SFA to the individual servers. If you have a small number of servers you may find you get more fine-grain control, better auditing, and fewer points of failure to do something like this article suggests -- skip the OpenVPN and implement fully server-side validated MFA directly to the server.
The ultra-paranoid would add an HMAC based port-knocking scheme and forget about primitives like fail2ban. This could either be based on a 3rd factor or reusing the existing private key.