What's the point of SSH over VPN connection?

VPN
1

I see a lot of people saying exposing SSH port to the internet is ill-advised even if only key-based auth is used and that it should be run over VPN/Wireguard instead.

  • What’s the point of this if SSH key and Wireguard encryption offer comparable levels of security and it’s not like you can expect an attacker to be able to crack either? What are common use cases for Wireguard?

  • Should you run all typical services over Wireguard then or are there cases where you shouldn’t?

  • Does this make stuff like Fail2ban/Crowdsec redundant (if I understand correctly, Wireguard uses UDP so won’t will only respond to unwanted connections)? Would Fail2ban/Crowdsec offer any benefits for ports that are not opened?

  • Are there any other general rules to improve a firewall besides the default of denying all incoming connections except required ports?

2

Any SSH server exposed on the internet is being continually slammed by all the botnets. You only need to tail the logs to see that.

A VPN will likely prevent this, which will save you power/cpu from people attacking the port all day and also the risk of them actually finding their way in. Or at the very least, they’d have to compromise your VPN first.

3

SSH provides a secure shell, WireGuard provides a network connection to a private network. They are different use cases that can be used without each other. You wouldn’t want anything less secure for either, at the risk they’d be abused on their own.

4

In my mind a vpn is simpler. Set up the vpn then you can restrict everything to being lan only. Simpler to set up and less to worry about.

5

From a practical point of view, when I want to print something at home, or grab a file from NFS, check my intranet documentation, surf with pihole blacklisting enabled, remote desktop into my workstation, … why try to do that all over SSH if you can just set up Wireguard and do it all remotely like you’re at home?

Apart from security, makes no sense to me to expose SSH honestly. :wink:

6

What’s the point of this if SSH key and Wireguard encryption offer comparable levels of security and it’s not like you can expect an attacker to be able to crack either? What are common use cases for Wireguard?

SSH is far more likely to be attacked and has a larger attack surface, especially if you use default ports. This also means your server is going to be slammed with attacks even if none of them go through.

Also, as other posters have noted, using multiple layers of security is often a good idea.

I use wireguard for two reasons:

  1. Remote VPN to hide traffic from carrier/ISP or change perceived geolocation.
  2. VPN into home network to access local network services, many of which I really don’t want to expose to the internet as I don’t trust their security as much.
7

Are there any other general rules to improve a firewall besides the default of denying all incoming connections except required ports?

I would look up some ssh hardening guides - particularly ones for public facing services (maybe linode or digital ocean - both have ssh hardening guides but I don’t recall off my head what’s covered in each). But there’s lots of stuff you probably want to tighten up in your sshd_config like using a non-default port (most bots target port 22 explicitly so simply picking anything else helps avoid that), disabling root access, disabling password auth (bc otherwise password can be brute forced), whitelisting allowed users/ips if possible, tightening up allowed ciphers/algorithms (definitely disable ecdsa - it’s both theoretically vulnerable to quantum computers and according to the arch wiki there’s also mentions that people suspect that the NSA can break it. If you are using rsa, make sure you use a minimum of 3072 bit key lengths, etc).

There’s also some more advanced stuff. One of the things I saw while researching my own ssh hardening that I would like to try (but currently don’t have a working setup for) is called port knocking. The idea is that not only will key-based tokens be required for auth but even before that, the client has to request a specific sequence of ports before they are even allowed to talk to the ssh service and begin the auth process (like a secret knock on a door).

I also saw at least one guide talking about setting up ssh as a tor hidden service.

Sorry for the lack of links… On phone. But I can probably dig some of them up later if there’s anything you’re interested in but having a hard time finding. Lmk

Fail2ban

There’s also an alternative service called sshguard that is supposed to work similarly. Might be better. Might be the same. Haven’t explored it enough yet but it’s on my “things to look into if I ever get any free time and don’t waste it doomscrolling on reddit” list.

8

I use SSH + IP whitelisting. Don’t bother with VPNs. Am I missing something?

9

Nothing bad at all with having SSH open. As long as password auth is NOT possible, then a break in is very, very unlikely.

Downside: Logs will get spammed. But that’s about it.

10

The analogy, however limited, might be to have a well-guarded door with sophisticated locks and mechanisms in place, allowing entry for those with the right key (=SSH server on port X, using all there is to securely log in) or having nothing at all appearing for those casually or even closely looking for… doors of any kind (mentioned server, but not running on any interface which is open to the wider Internet).

In that picture, the sheer existence of the door (when viewed from the outside) is the differentiating factor. And since no fancy door lock protects against exploits of the mechanisms in use, the safer bet, in relative terms, is to not even offer a door in the first place.

If all of that is worth the hassle is purely subjective of course. To my mind, the less experienced one is, the more secure one should set oneself up as even a broken layer (say there’s an exploit in the PubKey authentication or a simple config error) can still be mitigated to some extend by the other layers in place.

Since the overlay VPNs like ZeroTier or TailScale are so easy to set up and also come for free, I’d say they are worth looking into at least: https://www.youtube.com/watch?v=6M8LIl4UzwI&t=209s

But, ‘surely,’ you will say, ‘those exploits are rare and most things are patched after years of operation!’ Well: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=OpenSSH

(yeah, keeping that OpenSSH up to date is one thing, but it has some dependencies, right? In short: Add layers, they rarely all fail at the same time)

11

What’s the point of this if SSH key and Wireguard encryption offer comparable levels of security and it’s not like you can expect an attacker to be able to crack either? What are common use cases for Wireguard?

SSH is pretty secure by itself, if you follow all the guidelines (for example, disable password login, disable all logins for users that don’t need this access (like users services create when you install them) etc)

The use case for Wireguard is being a VPN. When you connect via Wireguard is just like if you are connected directly to the same network of your server. Like, if I traceroute the IP of my server through Wireguard, it just one hop away:

traceroute to 10.11.12.1 (10.11.12.1), 30 hops max, 60 byte packets
 1  server.vpn (10.11.12.1)  221.807 ms  221.809 ms  221.784 ms

Also I’m on the same network of the other Wireguard clients, so my mobile phone can talk directly to my desktop computer even when I’m away from home. This is what a VPN is used for, make you a Virtual Network that is Private.

Should you run all typical services over Wireguard then or are there cases where you shouldn’t?

Depends. If I run my regular webserver over Wireguard, well, nobody will be able to see my website! But for example, my Jellyfin server is only behind Wireguard, there is no need to it be exposed to the entire internet. You run things behind Wireguard if you want them to be private.

Does this make stuff like Fail2ban/Crowdsec redundant (if I understand correctly, Wireguard uses UDP so won’t will only respond to unwanted connections)? Would Fail2ban/Crowdsec offer any benefits for ports that are not opened?

If you put a service behind Wireguard (or any other VPN) yes, fail2ban and similars will be redundant for that service. But you could enable Wireguard to crete logs and configure fail2ban to block IPs that attempt to connect but don’t provide a correct handshake. It will appear in the logs like this:

Sat Mar  6 20:41:31 2021] wireguard: wg0: Invalid handshake initiation from 203.0.113.2:51820

Never saw anyone doing this, thou.

Are there any other general rules to improve a firewall besides the default of denying all incoming connections except required ports?

A simple firewall like UFW will just allow you to block ports. But you can improve with other software too. The firewalls that perform DPI (Deep Packet Inspection) for example can detect certain traffic even if not using standard ports. So lets say you let your SSH only behind a Wireguard and install a DPI Firewall that is configured to block SSH connections on the public IP. And lets say you got a backdoor that creates an SSH server on a random port. The moment an SSH packet arrives, the DPI firewall will notice it and block. I never used such software so I can’t help with this one, besides knowing it exists.

One thing I noticed happening to my webserver is that several bots try to look for vulnerabilities in some web software. I get several hits on /wp/admin and other well know paths that of course return 404 errors. I configured fail2ban to jail the IPs that try to do that. A regular firewall can’t do it because I would be able to only open or close the 443 port. Fail2ban on the other hand can keep an eye on my webserver logs, and include firewall rules to block those IPs on the fly, and also keep a tally of what is blocked and for how long, to remove the blocks after a while.

12

I keep SSH open but without password login. Some public networks block wireguard but SSH-tunneling works (sshuttle) so I have a VPN even in those situations. SSH is supposed to be secure even when exposed, but of course you need to configure it properly.

13

SSH is #1 target, and it had security flaws in the past.

SSH is a conglomeration of legacy protocols, thousands of knobs and bobs.

Easy to misconfigure, actually misconfigured by default, has to allow password login first time, to set up keys - that’s how most new server get hacked. People/bots try to login as soon as its online.

Wireguard is a very simple protocol, the algorithm “fits on a napkin” so to speak, whilst openssh requires a phonebook. Wireguard is widespread and support by almost every platform. Even my decade old router (a 2013 Fritzbox) got an update that added Wireguard support…

Setting up wireguard costs zerro money and gives me tons of peace of mind.

14

You’ve got a lot of good answers here, but FWIW, if you ever want to do this professionally, no decently sized organization with a halfway competent IT department is going to expose ports like SSH to public IPs.

Someone commented security in layers, and that’s very much the case in the professional world, you’ll always be required to VPN in then use the services you want to use.

15

If you don’t have a VPN already, I could see your argument making sense. If you have a VPN already, then why expose more services publicly than you need to?

16

I would say it’s more important if you’re working with other people who also need SSH access. If you run your own server and are the only owner of your SSH key, the VPN may be unnecessary as long as you’re using a passphrase, nonstandard port, and fail2ban.

Others may be more haphazard with their keys or get hacked… thus a VPN may add that extra layer of security assuming the VPN access wasn’t also compromised.

17

When I took over IT for a small company a few years ago they had SSH open to the Internet along with many management ports.

I reviewed the logs and found numerous attacks on those ports, fortunately none appeared successful. I blocked them all and use a VPN to connect - only one attack surface now, and it gets attacked regularly, but it’s quite secure (so far, knock on wood).

18

Onion’s got layers!

-Donkey

19

I have SSH configured on the standard port with nftables rules that does the same thing as fail2ban. I always use ssh keys to log in, but I do have one username that is allowed and you need a password and a MFA code.

20

Wireguard supports only public key authentication while ssh supports user/passwords as well with common passwords for root are still the thing. So bots try those as the payoff of getting access totally justifies sending millions login attempts. With public key cryptographs there are no common keys.