In my professional opinion, when you are talking about VPN vs an SSH login, you’re talking about two different things.
VPN grants access to a network wherein you can then access other resources on that network. Those resources will likely have their own form of authentication.
SSH grants access to one machine. That one machine could be a proxy into the network if it’s compromised. Logs on other machines will report the ssh machine as the source.
Both are secure methods assuming you use something like Wireguard or OpenVPN for the VPN and SSH with secure algorithms.
However, security breaks down from time to time (vulnerabilities, bad configuration changes, etc). For this reason you are better off setting up a VPN inside a separate device that is not an endpoint (firewall or a dedicated appliance) and has very limited access. This provides you with a few benefits:
Unlikely to accidentally misconfigure
A single surface area of protection. You don’t have to protect multiple services and ports.
Most VPNs have MFA capability. Ssh does not have it natively.
If the VPN security is compromised, you still have other authentication methods an attacker must circumvent to get to the destination machine. It’s layered security. The harder it is to attack you, the most likely the attacker will move to an easier target.
So, yes, ssh is very secure, but it’s not perfect. Nothing is. Plan for the worse.
I don’t recommend either. The fewer holes in the router the better.
Use a cloud brokered connection to get access. There are many flavors from ZeroTier to CloudFlare Tunnels.
Something else to ponder is using a Raspberry Pi and RealVNC Connect which is their cloud brokered VNC access. It’s free for all Pi owners and the Raspberry Pi OS comes with VNC Server already installed.
Even if you use another VPN solution, having a Raspberry Pi accessible this way lets you have a plan B if the VPN goes awry.
I have used RealVNC Connect and Raspberry Pi boards for years.
Both are fine, but SSH over a VPN (particularly WireGuard) would be “better”. For the simple reason that WireGuard doesn’t talk back, it will only respond to an authenticated request.
From a security perspective this is better as the attack surface is zero, the attacker doesn’t know you are there as nothing would show on a port scan.
As highlighted though, SSH is industry standard, and as long as you are using secure encryption algos you should be good. Many firms will still whitelist access to SSH (e.g, on prem to cloud).
Open SSH port is as insecure as your password. If you use a secure password then you’re safe. If you don’t use a password at all (PUBLIC/PRIVATE KEY) your even more safe
It’s not that “SSH is too risky” it’s because people who typically want to expose it don’t know how to set it up properly and then come here asking why they got owned.
I expose ssh on both my main homelab server and my mail server in AWS, with fail2ban blocking all ports when any of the jails are triggered. I’ve got jails for postfix, dovecot, haproxy, and ssh.
I haven’t set up a VPN yet, but may do so in the future. Most of the time I’m at home and don’t need a VPN. Using ssh allows me to do most anything if I am remote. I use keys for authentication, which pretty much eliminates MitM attacks unless somebody compromises the server.
All exposed services have encryption available, and anything that does authentication enforces encryption.
If you have the capability, restricting ingress rules at your firewall to trusted CIDRs for service ports that are not strictly public is never a bad idea.
VPN has always seemed a better solution for me at least when it comes to providing remote access for administrative purposes. Encrypt everything, leak nothing, eliminate State and ISP actor MitM snooping, logging, etc… especially on admin traffic.
All of our hosted VPS and cloud networks include security rules removing TCP/22 ingress from 0.0.0.0/0, even though that is a default and set CIDRs for admin staff home /32 public; also ingress for all corp regional on-prem VPN endpoints and proxies.
Both a rain jacket and an umbrella can equally protect you from rain.
Some people prefer umbrella because you can fit multiple people under it if needed. Others prefer a rain jacket because they don’t like the hassle of carrying around the umbrella and they enjoy feeling the rain. And I’m sure some prefer the jacket just because it matches their style.
Also you mention “folks say exposing SSH is too risky”. If you don’t know how to zip up your rain jacket or forget to pull up your hood, then yeah its very risky. But the rain jacket itself isn’t necessarily risky. One can argue that some umbrellas flip the other way around when there is enough wind. So there is that as well.
In a best case scenario if someone exposes SSH, they should also have something like fail2ban or crowdsec installed so that it bans IP addresses that still try to force their way in. Am I wrong?
A lot of compliance frameworks prohibit exposing SSH to the internet. People then, understandably, confuse arbitrary compliance requirements with best practices.
I’ve used key based authentication for over a decade along with disabling password based authentication. The later kills 99% of the bots that fail2ban attempts to stop.
As with a VPN, you need to subscribe to their security announcement mailing lists so you’re aware of vulnerabilities.
For defense in depth security you do this, plus have a vpn.
Theres no reason to enable SSH on a public interface though. It’s risk with no reward. Risk in this instance is defined by the amount of things people can touch outside your network, the surface area. Allowing SSH from the public internet just doesnt make sense given the alternative of VPN
Follow up question is why disable password login? If I use a password manager and generate a 32 character randomized password, is this inherently less secure?
When we setup customer VMs at work, we typcially change the port also and get them to setup a private key and if a customer wants a VPN we would ether get them to use 2FA or use Duo via our ASAs