Both use industry-standard encryption and are battle-tested, but I see people here scoff at exposing ssh on the public internet, but recommend setting up a VPN. If you set up each up in the “normal” way (ssh with key-based auth; VPN using wireguard), are they not similarly secure?
Properly setup SSH isn’t risky. Most people that say that are just parroting stuff they see all the time. I’ve had SSH open for years. SSH is a very secure software from OpenBSD project (another very security-centric project) and is used widely by governments and corporations world-wide.
I just typically recommend VPN more for practicality because usually people are asking about it to access their home network remotely. In such case, VPN has the advantage that once you’re logged in, you can access all the remote machines as if you’re on the LAN. With SSH, you only have access to the SSH machine. You could set up tunneling, but it’s more complicated to setup in my opinion.
If you do decide to use SSH, make sure you are using either ed25519 or RSA with at least 4096-bit key length and disable password-based login.
- “exposed” SSH is noisy thanks to botnets trying to bruteforce or stuff stolen credentials… using an uncommon or unique username, disabling passwords and setting up pubkey auth negates the viability of these attacks but it still shows up in your logs, which newer users get paranoid over.
- then for wireguard, its less noisy since it doesn’t respond to unauthenticated traffic. so as long as your firewall is dropping packets instead of rejecting them, it’s undetectable via port scan. plus it gives you a private ip address which you can easily bind your services to versus having to tunnel individual ports over SSH.
Here’s something I don’t see anyone saying, from a corporate security perspective though;
-
SSH is inherently responsive. It will respond even on a failure. Even establishing a session can give the source a bunch of information, like your SSH version, KEX, Ciphers, etc. If you have a fancy SSH banner, anything in that will go into the list. It can even get the OS and version you’re on in some cases.
-
Usually SSH isn’t run on your router, but port forwarded to an internal device. That means there’s a hole in your router’s firewall, and if either service is misconfigured it could allow the attacker to pivot to other internal devices.
-
VPNs usually run on the router, and should have multiple levels of authentication and authorization. For example, OpenVPN can be set to completely ignore connection attempts without a specific key. If it doesn’t respond, the attacker doesn’t know it’s there.
-
You can also have restrictions on your VPN’s firewall so that VPN clients have a limited subset of services they can access. Setting up an SSH bastion is far more knowledge intensive.
-
If you’re forwarding SSH on the default port, an attacker might wonder what other services you’re running and give you a full scan. HTTP/S, VPN defaults, any other standard default ports, they might start poking harder, and your logging is going to fill up real quick.
-
Probing attacks are trying to gain access primarily, but gathering information is a close second. Shodan is a thing and it literally sells this data as a business model. Other kinds of sites are less reputable.
Again, corporate security mindset here.
The answers here are missing the mark completely.
Encryption is the same.
The security concern with SSH is not about the encryption. SSH is for management of a box. You open a secure (encrypted) shell remotely to run commands on another machine; that is the purpose of SSH. You don’t run commands over a VPN.
If I compromise your VPN, I get layer 3 access to your network. If I compromise SSH with root privs I own your machine, and likely many others.
In an enterprise environment, it is common to have “jump boxes”. For example, I worked for an ISP that had multiple edge routers that customer’s traffic was transversing. Access Control Lists prevented SSH from any IP that was NOT one of the jumpboxes. I could only SSH to the routers from the jumpboxes (running RHEL), which where located on our network, and required MFA (multi-factor authentication) to log into, and then still another set of credentials to SSH to the routers.
If those ACLs where not in place, a customer/bad actor could potentially get the password for the router and wreak havoc for thousands of other customers transversing that router.
It has absolutely nothing to do with the encryption when people say not to expose SSH to the public Internet.
Having SSH be internet facing is fine, you just need strict security controls as with any public facing service.
Why do folks here typically recommend setting up a VPN for secure access, but say that exposing SSH is too risky?
I’m not sure they do… I don’t see it too often…
Some people do say this, but not going to say typically.
Personally, I have SSH open to the world on it’s normal port.
Changing the port gives it a few more days before it is found, but it is still found and listed in the public lists of SSH servers.
Changing the port numbers I used to do but I stopped for a few reasons…
-
I had to remember which port I changed it to…
-
Some places restrict which ports outbound connections are made to, 22 might be allowed but a random port not.
-
It doesn’t do anything accept add a couple days before it is listed.
Port-knocking is another option some people use to hide it, but goes back to 1 and 2 above.
All but one of my OSs will cut the connection before the password prompt appears, the one that will still show Password, doesn’t accept a password if the account has a key saved.
I use SSH to fix the system if my VPN won’t connect.
Linode / AWS / GCP all give you SSH, the issue is if people are asking if it’s ok they likely don’t know how to secure it. Implementation is the biggest hurdle.
Wireguard for example is UDP which is harder to detect if a port is open or not during a port scan.
SSH is using TCP so it’s easier to detect during a port scan.
You’re right, with a few non-default options SSH is just as internet-safe as a VPN. SSH can be hardened quite well.
However, there are a few advantages to a VPN - if you run one over UDP, it won’t show up from a port scan, while SSH being TCP will (though Port Knocking mitigates this). I use OpenVPN with TLS Auth, so a client cannot even initiate a connection unless it has the necessary key. And a VPN allows you more granular access to the machines behind it by defining routes or specifying a subnet with firewall rules.
There’s a lot of crossover in functionality but both are secure options when correctly configured. And SSH is difficult to configure incorrectly unless you really don’t know what you’re doing.
It depends. Technically, either are in the same risk category. If properly setup, either would also be fine.
Folks here usually have tech jobs also and tend to recommend time honored best practices adopted from their respective industries. From that perspective, a more structured corporate network, a VPN would make more sense because the remote device is likely managed or capable of being managed. In addition, it is easier for isolation when using a VPN in those environments. So, folks recommend what works.
I use a VPN instead of exposing a SSH port for the same reasons. My homelab is a near mirror of my enterprise networks in many technical aspects, including the VPN, etc. I can use it to test out new tech and learn existing tech that I am exposed to daily.
So, that’s probably why you see these recommendations. If you want to use ssh, just set it up properly and you will be fine. Follow the rules with any exposure (regular updates, monitoring, etc) and there are usually no issues.
There is no problem exposing SSH if configured securely. We typically do not do expose SSH externally and our SSH servers are all* set to key-only.
- most really. Development servers, test servers, etc might not yet be configured.
A poorly configured VPN that passes traffic is more secure than a default SSH server. When you are setting up a VPN, you are doing it to allow remote access security is top of mind. The VPN settings are unlikely to change. When you do make a change, you are conscious of the risks.
In many cases, SSH comes installed and working.
SSH in its default configuration is not secure enough for exposing to the internet. It requires knowledge and action to become secure.
So, the answer is both can be safe to expose to the internet. However, the reason to deploy SSH behind a VPN is to mitigate human error, lack of knowledge and process failure. It is much harder to accidentally allow access if you have your SSH behind your VPN.
If you have a busy environment, the security team or senior techs can manage or review the VPN. Then the junior techs or devs can spin up servers with SSH access that do not require immediate review from the sec team to ensure they are configured correctly.
So, this is a bit of a misunderstanding that is being spread. SSH isn’t insecure as such. But it’s still recommended to run it behind a VPN anyway. The reason for that isn’t because SSH is insecure, but rather because of how powerful ssh is should you break it. IF you have a security issue in SSH and you run it publicly, you’re getting exploited very quickly. If you run it behind a VPN however, you now need to break both the VPN and the SSH server at the same time. Now if you never patch your stuff it doesn’t matter because both will sooner or later have an exploit found. But with proper patching, the odds that both services would have an unpatched exploit at the same time is drastically lower.
This also isn’t unique to ssh, you’re recommended to run EVERYTHING that should only have private access behind a VPN for the same reason.
Here’s the thing, I don’t see running SSH exposed to the public internet as a security risk, however, there are a couple of valid reasons to suggest running it behind Wireguard.
- A SSH setup is only secure if you can make sure it is properly configured (no password login) and updated;
- SSH runs on TCP, and that means a port scanner will be able to detect it. Wireguard runs on UDP - port scanning won’t work on it as all invalid packets are silently dropped.
So yes, running SSH behind a Wireguard VPN is most likely very paranoid but one can’t also say those people are wrong and dismiss advantages of a Wireguard UDP port that is stealth by design.
-------
Update:
The “stealthiness” of the UDP Wireguard port might depend on your firewall / operating system setup. Note that OS actively reject incoming packets on closed ports. So that one port with Wireguard running would stand out by not doing that. To avoid that, one should simply have a firewall rule to silently drop any packets on unused ports. That way all the ports look the same, with no way to tell if there is Wireguard listening somewhere without having a proper key.
By doing this change to unused ports you’re achieving three: 1) you remove this piece of intelligence from an attacker; 2) you slow down scans by forcing their tools to wait for a timeout and 3) you increase the difficultly of a DDoS because your firewall has to do less for unused ports.
Setting ports to “reject” should really only used on private networks so your users / systems so they don’t have to wait for a timeout if they hit something that was disabled / blocked.
It’s all a risk. Some people are more comfortable with their version of ‘more secure’.
Any standard port open on your router will get bombarded almost automatically.
You can do either but if you open ports for normal traffic like ssh, put it on a nonstandard port.
VPNs are easier to setup, and arguably more secure but everything you allow comes with it’s own risk.
I’m paranoid but I didn’t expose my VPN either when I ran one so I set up a reverse SSH tunnel through my cloud VM which I also don’t fully trust.
My firewall blocks all incoming SSH access except from 4 IP addresses in the world. 3 relatives and a VM in the cloud. I don’t trust the cloud provider so I don’t want to type any passwords or store keys on the cloud server.
When I’m in a hotel room with my laptop and a random IP address I start a reverse SSH tunnel through my cloud VM to home.
At home SSH runs on the standard port 22. My cloud VM runs SSH on port 3267 to avoid hundreds of failed bot login attempts per hour.
This sets up a tunnel from my laptop that listens on my laptop port 8888. It forwards all the traffic to my cloud VM on port 3267. The cloud VM then forwards it to my home-server on port 22
ssh -X -f -C -L 8888:home-server.domain.com:22 -N [email protected] -p 3267
Get an SSH terminal at home from my laptop through the tunnel
ssh -p 8888 user@localhost
Mount my home server on my laptop through the tunnel
sshfs -p 8888 user@localhost:/ /mnt/home-server
I use X2Go for remote full desktop access. It runs everything through SSH so I I do the same localhost port 8888 in my X2Go settings and it works great.
With terminal, filesystem, and graphical desktop access I’ve realized that I don’t actually need a full VPN so I turned it off.
Logs… the big redhat virus years ago would break in, hit my logs and then die because my system wasn’t redhat and didn’t provide what it expected. At the height of the thing they just scrolled and I kept having to save my disk from overfilling.
I love tailscale because it allows easy connection between my mobile devices.
Security? I’d trust SSH slightly more due to age/testing.
If you run ssh open to the internet, change the port from the standard 22 to some mostly unused five digit port. Left on port 22 you will see a multitude of hacking attempts each and every day. On some weird port there will be basically none.
Opening port 22 isn’t that risky unless you’re a high value target that can’t sustain a potential unhatched vulnerability for a couple hours. 22 open will be very noisy as bots try their credential lists on you though. You can use fail2ban or similar to block some, but there will always be more.
Just easier to switch to a different port either on the server or on the port forwarding translation.
Lots of Redditors just honestly feel more comfortable opening up VPN than SSH. Gotta have that warm fuzzy secure feeling holed up in mom’s basement.