Every implementation may contain bugs, even in SSH. What about port knocking?
Sure, but you’ll see a shit ton of attempted logins with port 22 open.
“SSH isn’t risky. However, it’s more common for users to setup SSH insecurely than VPN. And SSH paints a bigger target on your network. Thus, recommending VPN is easier.”
Would this be a proper TL;DR answer?
Use Tailscale and you don’t have to expose any ports!
SSH could have exploits that might let a user login without a password. Maybe not now, but in the future.
But with VPN, whatever you do, you still need the right certificate/keys to be able to talk to the server.
With the shitty rollout or IPv6 a lot of users are behind CGNAT, and simply don’t have the ability to expose SSH directly. That’s where VPN comes in.
Leave something with SSH enabled on a public interface with weak credentials set and see what happens. For a VPN typically this involves opening up a port, but using a lesser known port will get less attention from the things trawling the internet and jiggling door handles.
There’s a difference between a site to site IPsec VPN or a user access/ssl VPN with a split tunnel profile.
The difference in your question is that accessing ssh is done from a local network not a public one and the source comes from a internal port with a destination of an internal port typically handled by a firewall.
Further a default deny policy will just drop public packets to port 22.
Laptop (interface 1 internet) ( interface 2 ssl VPN) - remote site firewall (assigns laptop a internal IP and spit tunneling route) - laptop requests google.com (interface 1) laptop requests port 22 to some rfc1918 address (known route interface 2) - policy inspection on remote end "I see source:22 is allowed from (VPN address) allow session from source, source port to destination, destination port
A site to site VPN is always built tunnel on the edge of the networks (firewalls on each side typically) therefore a office pc at site A can always see site B providing a security policy allows it.
In the two VPN types SSH is invisible to the public internet. SSH is visible to any VPN session with a security policy allowing.
Further the server is not assigned a public IP address and is assigned a RFC 1918 address meaning it’s not publicly routable to begin with. To overcome this involves creating a firewall policy and NAT to build a session from public to private or private to public. (Directional) or both (bidirectional)
If we take the same server with only a internal 1918 IP and run a webserver then you create a directional policy and NAT on the firewall (allow any source from any source port 80/443 to ( internal server port ( webserver listening port) )
Now you have a directional public access to only a webserver port and no other port. Additionally no port is open from the server to any public interface. You would need to add a directional outbound policy to say allow for pulling updates.
The above is the enterprise way of doing it. In a homelab it may be less involved or complicated because of simpler networking devices and typically only 1subnet and or VLAN which means that security policies are less involved as once you get in everything is likely switched on 1 network.
This is more involved answer but should provide you a 10k foot overview of how it looks in terms of the security aspect because we aren’t just really talking about removing SSH from public but the entirety of the server itself is not publicly accessible even when public access is needed, when it is only a specific port is visible under specific circumstances.
I always felt SSH is actually more secure, it’s a simpler protocol so less chance of vulnerability. VPN is very complex, and also very complex to setup properly, so there is more room for error. Remember heartbleed? Although there was also shellshocker for SSH…
For very critical stuff that I also have physical access to, I tend to just setup IP restrictions on VPN and SSH. For web server that I don’t have physical access to, then I don’t have a choice but to leave it wide open, and just hope for the best. Using key pair auth instead of password, and having fail2ban can help.
As a side note I also wouldn’t consider keys to be 100% secure either. In theory, they could also be brute forced, so it’s still important to have something like fail2ban, though I don’t know if it is actually setup to detect key brute forcing as I never really tried it…
Same peeople that say logging into online banking on public WiFi is risky. Do you trust the TLS encryption between your browser and the bank or not?
I use ssh exposed. I always use keys and turn off password access though.
This reminds me… is port knocking still a thing?
Ideally you would use a VPN server for remote access, but still take a “zero trust” approach and not have the whole network wide open to VPN clients. So a remote user would need to authenticate with the VPN server and with the end system (eg SSH).
That provides you with a degree of defence in depth. An exploit against the VPN server still leaves an attacker in a somewhat walled-off system, needing additional work to get further. An exploit against SSH can only be exploited by an attacker who is already through the VPN.
That said, not every network requires that degree of security. If it’s truly a homelab with little or no personal or confidential info on it (as opposed to a home server with stuff like your documents and contacts on there) then you might be comfortable opening SSH directly for simplicity.
Exploits are the main threat anyway. Following all the security best practices for SSH configuration won’t necessarily help you there, and vulnerable systems will be rapidly discovered by automated scanners.
Feel it’s more “Right tool for the right Job”. Both have their uses and I use them both in my farms. AKA. I have systems on-prem, in AWS, and in Azure. Most my public sites are on Azure and AWS and I do not use a VPN, unless I’m moving other traffic that I, A) cannot encrypt naturally b) contains immediate “secure” data. Both options are related to moving traffic from one ENV (Farm) to another.
things like public web sites, SSH is perfect.
I agree. They don’t know what they are talking about.
If I only want to connect to one machine I usually use SSH. VPN to me seems like overkill.
If I plan on accessing multiple boxes, I will more than likely spin up a VPN.
TBH, most of the time I use what will satisfy my needs and I feel like configuring.
I used to be one of those ignorant people who believed SSH was not secure to have open to the internet, since I was only using password based authentication and a password, while it was secure from quantumless cracking, was not changed often and may have been reused a few or more times 
I’ve moved to EDCSA key-based authentication on all my machines and will never go back. It’s perfectly safe to expose to the internet as long as you only allow key based authentication.
If you’re extra paranoid, you can change the port too; I’ve done that before just to reduce the load from scanners/skiddies who check every IP on port 22 and clog up my TCP sessions, but even then that’s a bit unnecessary imo.
Nothing can go wrong if you disable password. No need to change SSH port or anything. If someone can exploit your key based SSH he must be the mighty guy and there is nothing you can do.
Because if you don’t setup certificate authentication you are opening yourself up to brute-force attacks against your password auth from internet sourced attackers.
I wouldn’t expose either. But if you do need to get some type of access, I do like Tailscale or OpenVPN. The first not needing an open port, the latter being well tested and offering several layers of authentication and the ability to restrict network access/exposure when deploying through something like pfsense.
If you disable the part where you can login as root via ssh and don’t use easily guessable passwords, you are good to go.