The author goes into this in the beginning by stating that the admin can have "PasswordAuthentication no" in sshd_config and users with keys can still have weakly protected (or unprotected!) keys.

In other words, you can lead a correct horse battery staple to water, but you can't make it protect its key pair with a strong password.

That's a separate issue though. You can have weak/unprotected VPN keys as well.

I think the author's argument about using VPNs is more a "right tool for the job" thing. SSH is fine for remote shell, but then you start to need other network service access. You can use SSH tunneling, yes, but a VPN is better suited.

So, in a nutshell, the point is "only expose a single service." And since a VPN is more flexible than SSH, might as well go with that if you have the choice. You can of course make counter arguments along the lines of "expose only the minimal amount of functionality" or whether you think a VPN or SSH is more secure.

A VPN will allow you to tunnel all of your traffic over a secure connection.

In SSH, you can tunnel ports, but that only secures traffic at that port. You can use a SOCKS proxy, but that only secures traffic configured to go through it. You can use the -w option and use IP forwarding, but then you're running TCP/IP over the SSH protocol which is bad. This is the closest you'll get to emulating what a VPN provides.

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.