SSH is not at all risky if you disable password authentication. There's essentially zero chance that someone guesses your private key, though you might get annoyed with all the login failures spamming your logs. Fail2ban helps with that if you care, though I don't personally bother these days.
So that’s generally my train of thought, but from what I know there were serious vulnerabilities discovered in OpenSSH throughout the years, doesn’t it increase the risk for open ssh port or were the vulnerabilities discovered never touched those areas of ssh authentication. Seems to me that tools like tailscale and so on aren’t open to this sort of risk but I definitely can be wrong
A bigger problem I think would be someone discovering a pre-auth 0day in the code. So the important thing would be to not allow the entire internet unrestricted access to whatever's running the SSH server.
They probably mean leaving ssh open to all ips. Take a look at your auth failure logs to see the thousands of daily attempts to compromise your server using default passwords. Most of those are low effort and low risk. Sometimes the bots will try password stuffing. Disabling password auth in sshd config is good practice.
Fail2ban also helps block repeated attempts like that.
There’s also the risk of a zero day RCE vulnerability in ssh (though I’ve not seen one in the 20 years I’ve been paying attention )
I tend to not expose ssh to the world and log in with some other method to pass the perimeter (VPN, IP whitelist, tailscale) and the ssh from inside.
fail2ban seems like security theater for a keys-only SSH server, and it won't help against zero days either (unless it happens to be one that requires many attempts).
The only thing it helps with is log spam, but then why not just configure SSH to not log login failures?
> If the SSH connection is set to disallow passwords and only authorize via SSH keys, how big of a risk is this
low risk, do this. Keys (ed25519,4096 rsa) are impractical to brute force. However I'd also recommend:
- use a different port than 22 (add your .ssh/config for easier UX if needed) - port 22 can get incredibly noisy with tons of bots probing
- disable passwordAuth, disable PermitRootLogin - use a normal user with sudo for your ssh
- consider a vpn please - I use tailscale, but I hear headscale is good - then use UFW to only allow SSH from the tailscale network (I generally allow all network on tailscale). Tailscale wrote a guide on this here [1]
- do not add and forget authorized_keys from machines you arent using
- I'm especially worried about how people keep giving Clawdbot/Openclaw access to all their machines, key auth means the machine is authorized on your server
- For new servers I often just add all my public keys to them (github lists all your keys at github.com/GH_USERNAME.keys
Thanks a lot for the detailed response. I see Tailscale pop up here often and have been meaning to better understand how it could fit into my typical hosting setup, so I appreciate that reference.
For additional context I usually host on a shared or dedicated VPS, and in this case am managing a WordPress site I inherited. It seems to me that if the SSH connection is restricted by IP and limited to keys, there are much larger risks involved in hosting a WordPress site publicly available on the internet w/ dozens of plugin dependencies.
> key auth means the machine is authorized on your server
Not necessarily: Depends on whether your key is passphrase-protected and how your SSH agent is configured (if you use one). You can have the standard OpenSSH one ask you for confirmation of every key usage, for example.
> consider a vpn please
But also consider how you'll fix a broken VPN without SSH access.
Many people keep offering advice to consider a VPN and while VPN is very usefull, I have not yet come accross a reason why not use ssh auth. Like what can actually happen? From my pov the risk of running all sorts of userspace software with internet access is much greater, even without port forwarding.
You said “legal” risk, not “security” risk. You’ll need to get more information on what risks they are trying to mitigate and talk to a “legal” expert rather than engaging on a technical or security basis.
Most more professional environments use VPN and bastion hosts for this purpose.
SSH is a risk because you’re trusting the users and client to not be idiots or get compromised. In general, people tend to do stupid things. If it’s just you and your server, potentially a different story.
It’s like sharing secrets with people, the more who are involved, the less likely the secret will be kept.
No, but if you do it badly of course it will be. How else do they expect you to login? Unless they are giving you physical access, SSH by all measures is the best way to connect. Leaving it unmaintained is the worst way forward. Just follow best practices and patch on a regular schedule. They seem to be worried about the wrong problem here. Where is your client's security team and why are they ignoring this issue? If they don't have one, then tell them to get one before complaining about something they know nothing about.
If you're hosting on a public cloud, you can use a feature like AWS Session Manager to connect "through the backdoor" (via the guest's private communication with the hypervisor) without actually opening the ssh port to the world. This should fully address the client's concerns. None of my servers have ssh exposed at all.
Best practices usually call for not exposing the SSH endpoints to the public internet. The principal risk is vulnerabilities in the underlying SSH server implementation. Historically, critical flaws that can compromise you are few and far between. However, these days AI is already starting to become adept at reverse engineering.
If you must, you'd typically use a bastion host that's configured just for the purpose of handing inbound SSH connections, and is locked down to a maximal degree. It then routes SSH traffic to your other machines internally.
I'd argue that model is outdated though, and the prevailing preference is putting SSH behind the firewall on internal networks. Think Wireguard, Tailscale, service meshes, and so on.
With AWS, restricting SSH ports via security groups to just your IP is simple and goes a long way.
But doesn’t your argument that the principal risk [with ssh] is vulnerabilities also apply to the alternatives you say is best practice? Firewalling off ssh (but not http(s)) has the risk of vulns in the FW software. Tailscale, wireguard etc also has the risk of vulns in that software?
So what’s the difference in risk of ssh software vulns and other software vulns?
Also, another point of view is that vulnerabilities are not very high on the risk ladder. Weak passwords, password reuse etc are far greater risks. So, the alternatives to ssh you suggest are all reliant on passwords but ssh, in the case, is based on secure keys and no passwords. Should “best practices” not include this perpective?
But saying ssh is a risk “on principle” due to possible vulnerabilities, and then implying that if wireguard is used then that risk isnt there is wrong. Wireguard, and any other software, has the same vuln risk “on principle”.
> For vulnerabilities, complexity usually equals surface area. WireGuard was created with simplicity in mind.
That is such consultant distraction-speak. Simple software can have plenty vulns, and complex software can be well tested. Wireguard being “created with simplicity in mind” doesn’t not make it a better alternative to ssh, since it doesn’t mean ssh wasnt created with simplicity in mind.
I don’t disagree that adding a vpn layer is an extra layer of security which can be good. But that does not make ssh bad and vpn good. Further, they serve two different purposes so its comparing Apples to oranges in the first place.
Or how large companies actually think about this risk in the real world. Expose SSH ports to the public internet willy-nilly and count the seconds until their ops and security teams come knocking wondering what the heck. YMMV of course, but that's generally how it goes.
Are critical SSH vulns few and far between, as far as anyone knows? Yes.
Do large companies want to protect against APT-style threats with nation-state level resources? Yep.
Does seeing hundreds if not thousands of failed login attempts a day directly on their infrastructure maybe worry some people, for that reason? Yup.
You call it consultant distraction speak, I call it educating you about what Wireguard actually is, because in your original reply you suggested it was password-based.
>Further, they serve two different purposes so its comparing Apples to oranges in the first place.
Not when both can be used to protect authentication flows.
One is chatty and handshakes with unauthenticated requests, also yielding a server version number. The other simply doesn't reply and stays silent.
>Simple software can have plenty vulns, and complex software can be well tested.
In this case, both are among some of the most highly audited pieces of software on the planet.
I’m calling it consultant speak because your response to an argument is to bring up something else, instead of actually responding.
The same with this last reply; you can keep throwing out new points all you want, but thats not going to make you correct in the original question.
Saying or implying that one software has a “principle” risk of vulnerabilities that another software doesn’t is plain and simply wrong.
And that has nothing to do with all the other stuff about layered defence, vpns, enterprise security, chatty protocols or whatever you want to pile on the discusion.
>So what’s the difference in risk of ssh software vulns and other software vulns?
I proceeded to explain how large companies think about the issue and what their rationale is for not exposing SSH endpoints to the public internet. On the technical side, I compared SSH to WireGuard.
For that comparison, the chattiness of their respective protocols was directly relevant.
Likewise complexity: between two highly-audited pieces of software, the silent one that's vastly simpler tends to win from a security perspective.
All of those points seem highly relevant to your question.
>... but thats not going to make you correct in the original question.
If you can elucidate what I said that was incorrect, I'm all ears.
You are still implying that wireguard are somehow different from ssh in its suceptibilty to vulnerabilities existing or being introduced into its codebase. And it simply is not.
Edit: codebase of ssh/wireguard implementations, just to be clear
WireGuard is 4k LoC and is very intentional about its choice of using a single, static crypto implementation to drastically reduce its complexity. Technically speaking, it has a lower attack surface for that reason.
That said, I've been on your side of the argument before, and practically speaking you can expose OpenSSH on the public internet with a proper key setup and almost certainly nothing will happen because it's a highly-audited, proven piece of software. Even though it's technically very complex.
But, that still doesn't mean it isn't best practice to avoid exposing it to the public internet. Especially when you can put things in front of it (such as WireGuard) that have a much lower technical complexity, and thus a reduced attack surface.
If your private key has a good passphrase and is suitably encrypted, say with ed25519, then that's probably as good as you can do other than physically going into work and storing everything in your head :-) Politely ask the client to suggest what they consider would be a suitable alternative.
I also setup git hooks to prevent accidentally checking in private keys or passwords into git or other version control systems. And if I'm travelling into or from work I also encrypt some stuff just in case I have a problem and the laptop is stolen.
ditto to everything here. If you really want to you can also change the port to something random to avoid bot spam. but you shouldn't have SSH accessible directly from the internet anyway.
If you are using only keys, make sure they are managed, tracked, securely stored and backed up. The last thing you want is to have a machine die that has the only private key for your environment.
SSH is not at all risky if you disable password authentication. There's essentially zero chance that someone guesses your private key, though you might get annoyed with all the login failures spamming your logs. Fail2ban helps with that if you care, though I don't personally bother these days.
> SSH is not at all risky if you disable password authentication.
ELI5, please. I understand it for passwords laymen use, but why is my 128 random byte password less secure than a key?
So that’s generally my train of thought, but from what I know there were serious vulnerabilities discovered in OpenSSH throughout the years, doesn’t it increase the risk for open ssh port or were the vulnerabilities discovered never touched those areas of ssh authentication. Seems to me that tools like tailscale and so on aren’t open to this sort of risk but I definitely can be wrong
The only one I can think of is the one on Debian where key generation used weak entropy, making keys guessable.
Given its sensitivity, OpenSSH is incredibly battle-hardened and probably better than almost everything else you can run on an exposed port.
A bigger problem I think would be someone discovering a pre-auth 0day in the code. So the important thing would be to not allow the entire internet unrestricted access to whatever's running the SSH server.
They probably mean leaving ssh open to all ips. Take a look at your auth failure logs to see the thousands of daily attempts to compromise your server using default passwords. Most of those are low effort and low risk. Sometimes the bots will try password stuffing. Disabling password auth in sshd config is good practice. Fail2ban also helps block repeated attempts like that.
There’s also the risk of a zero day RCE vulnerability in ssh (though I’ve not seen one in the 20 years I’ve been paying attention )
I tend to not expose ssh to the world and log in with some other method to pass the perimeter (VPN, IP whitelist, tailscale) and the ssh from inside.
fail2ban seems like security theater for a keys-only SSH server, and it won't help against zero days either (unless it happens to be one that requires many attempts).
The only thing it helps with is log spam, but then why not just configure SSH to not log login failures?
> If the SSH connection is set to disallow passwords and only authorize via SSH keys, how big of a risk is this
low risk, do this. Keys (ed25519,4096 rsa) are impractical to brute force. However I'd also recommend:
- use a different port than 22 (add your .ssh/config for easier UX if needed) - port 22 can get incredibly noisy with tons of bots probing
- disable passwordAuth, disable PermitRootLogin - use a normal user with sudo for your ssh
- consider a vpn please - I use tailscale, but I hear headscale is good - then use UFW to only allow SSH from the tailscale network (I generally allow all network on tailscale). Tailscale wrote a guide on this here [1]
- do not add and forget authorized_keys from machines you arent using
- I'm especially worried about how people keep giving Clawdbot/Openclaw access to all their machines, key auth means the machine is authorized on your server
- For new servers I often just add all my public keys to them (github lists all your keys at github.com/GH_USERNAME.keys
1: https://tailscale.com/docs/how-to/secure-ubuntu-server-with-...
Thanks a lot for the detailed response. I see Tailscale pop up here often and have been meaning to better understand how it could fit into my typical hosting setup, so I appreciate that reference.
For additional context I usually host on a shared or dedicated VPS, and in this case am managing a WordPress site I inherited. It seems to me that if the SSH connection is restricted by IP and limited to keys, there are much larger risks involved in hosting a WordPress site publicly available on the internet w/ dozens of plugin dependencies.
> key auth means the machine is authorized on your server
Not necessarily: Depends on whether your key is passphrase-protected and how your SSH agent is configured (if you use one). You can have the standard OpenSSH one ask you for confirmation of every key usage, for example.
> consider a vpn please
But also consider how you'll fix a broken VPN without SSH access.
Many people keep offering advice to consider a VPN and while VPN is very usefull, I have not yet come accross a reason why not use ssh auth. Like what can actually happen? From my pov the risk of running all sorts of userspace software with internet access is much greater, even without port forwarding.
You said “legal” risk, not “security” risk. You’ll need to get more information on what risks they are trying to mitigate and talk to a “legal” expert rather than engaging on a technical or security basis.
Most more professional environments use VPN and bastion hosts for this purpose.
SSH is a risk because you’re trusting the users and client to not be idiots or get compromised. In general, people tend to do stupid things. If it’s just you and your server, potentially a different story.
It’s like sharing secrets with people, the more who are involved, the less likely the secret will be kept.
No, but if you do it badly of course it will be. How else do they expect you to login? Unless they are giving you physical access, SSH by all measures is the best way to connect. Leaving it unmaintained is the worst way forward. Just follow best practices and patch on a regular schedule. They seem to be worried about the wrong problem here. Where is your client's security team and why are they ignoring this issue? If they don't have one, then tell them to get one before complaining about something they know nothing about.
If you're hosting on a public cloud, you can use a feature like AWS Session Manager to connect "through the backdoor" (via the guest's private communication with the hypervisor) without actually opening the ssh port to the world. This should fully address the client's concerns. None of my servers have ssh exposed at all.
How does the nature of remote access address the legal concern (presumably) about there being remote access in general?
That isn't my presumption about nature of the concern. In OP's other comment they specify that the client is specifically worried about the open port.
Well, if you allow remote access, you conceptually allow some kind of logical inbound connection, no matter how it's technically realized.
Best practices usually call for not exposing the SSH endpoints to the public internet. The principal risk is vulnerabilities in the underlying SSH server implementation. Historically, critical flaws that can compromise you are few and far between. However, these days AI is already starting to become adept at reverse engineering.
If you must, you'd typically use a bastion host that's configured just for the purpose of handing inbound SSH connections, and is locked down to a maximal degree. It then routes SSH traffic to your other machines internally.
I'd argue that model is outdated though, and the prevailing preference is putting SSH behind the firewall on internal networks. Think Wireguard, Tailscale, service meshes, and so on.
With AWS, restricting SSH ports via security groups to just your IP is simple and goes a long way.
But doesn’t your argument that the principal risk [with ssh] is vulnerabilities also apply to the alternatives you say is best practice? Firewalling off ssh (but not http(s)) has the risk of vulns in the FW software. Tailscale, wireguard etc also has the risk of vulns in that software?
So what’s the difference in risk of ssh software vulns and other software vulns?
Also, another point of view is that vulnerabilities are not very high on the risk ladder. Weak passwords, password reuse etc are far greater risks. So, the alternatives to ssh you suggest are all reliant on passwords but ssh, in the case, is based on secure keys and no passwords. Should “best practices” not include this perpective?
Good defense is layered.
For vulnerabilities, complexity usually equals surface area. WireGuard was created with simplicity in mind.
>So, the alternatives to ssh you suggest are all reliant on passwords but ssh, in the case, is based on secure keys and no passwords.
WireGuard is key-based. I highly suggest reading its whitepaper:
https://www.wireguard.com/papers/wireguard.pdf
Sure, no one said it wasnt layered.
But saying ssh is a risk “on principle” due to possible vulnerabilities, and then implying that if wireguard is used then that risk isnt there is wrong. Wireguard, and any other software, has the same vuln risk “on principle”.
> For vulnerabilities, complexity usually equals surface area. WireGuard was created with simplicity in mind.
That is such consultant distraction-speak. Simple software can have plenty vulns, and complex software can be well tested. Wireguard being “created with simplicity in mind” doesn’t not make it a better alternative to ssh, since it doesn’t mean ssh wasnt created with simplicity in mind.
I don’t disagree that adding a vpn layer is an extra layer of security which can be good. But that does not make ssh bad and vpn good. Further, they serve two different purposes so its comparing Apples to oranges in the first place.
>That is such consultant distraction-speak.
Or how large companies actually think about this risk in the real world. Expose SSH ports to the public internet willy-nilly and count the seconds until their ops and security teams come knocking wondering what the heck. YMMV of course, but that's generally how it goes.
Are critical SSH vulns few and far between, as far as anyone knows? Yes.
Do large companies want to protect against APT-style threats with nation-state level resources? Yep.
Does seeing hundreds if not thousands of failed login attempts a day directly on their infrastructure maybe worry some people, for that reason? Yup.
You call it consultant distraction speak, I call it educating you about what Wireguard actually is, because in your original reply you suggested it was password-based.
>Further, they serve two different purposes so its comparing Apples to oranges in the first place.
Not when both can be used to protect authentication flows.
One is chatty and handshakes with unauthenticated requests, also yielding a server version number. The other simply doesn't reply and stays silent.
>Simple software can have plenty vulns, and complex software can be well tested.
In this case, both are among some of the most highly audited pieces of software on the planet.
I’m calling it consultant speak because your response to an argument is to bring up something else, instead of actually responding.
The same with this last reply; you can keep throwing out new points all you want, but thats not going to make you correct in the original question.
Saying or implying that one software has a “principle” risk of vulnerabilities that another software doesn’t is plain and simply wrong.
And that has nothing to do with all the other stuff about layered defence, vpns, enterprise security, chatty protocols or whatever you want to pile on the discusion.
Your question was this:
>So what’s the difference in risk of ssh software vulns and other software vulns?
I proceeded to explain how large companies think about the issue and what their rationale is for not exposing SSH endpoints to the public internet. On the technical side, I compared SSH to WireGuard.
For that comparison, the chattiness of their respective protocols was directly relevant.
Likewise complexity: between two highly-audited pieces of software, the silent one that's vastly simpler tends to win from a security perspective.
All of those points seem highly relevant to your question.
>... but thats not going to make you correct in the original question.
If you can elucidate what I said that was incorrect, I'm all ears.
You are still implying that wireguard are somehow different from ssh in its suceptibilty to vulnerabilities existing or being introduced into its codebase. And it simply is not.
Edit: codebase of ssh/wireguard implementations, just to be clear
Yes, the two are very different in that regard.
WireGuard is 4k LoC and is very intentional about its choice of using a single, static crypto implementation to drastically reduce its complexity. Technically speaking, it has a lower attack surface for that reason.
That said, I've been on your side of the argument before, and practically speaking you can expose OpenSSH on the public internet with a proper key setup and almost certainly nothing will happen because it's a highly-audited, proven piece of software. Even though it's technically very complex.
But, that still doesn't mean it isn't best practice to avoid exposing it to the public internet. Especially when you can put things in front of it (such as WireGuard) that have a much lower technical complexity, and thus a reduced attack surface.
If your private key has a good passphrase and is suitably encrypted, say with ed25519, then that's probably as good as you can do other than physically going into work and storing everything in your head :-) Politely ask the client to suggest what they consider would be a suitable alternative. I also setup git hooks to prevent accidentally checking in private keys or passwords into git or other version control systems. And if I'm travelling into or from work I also encrypt some stuff just in case I have a problem and the laptop is stolen.
ditto to everything here. If you really want to you can also change the port to something random to avoid bot spam. but you shouldn't have SSH accessible directly from the internet anyway.
If you are using only keys, make sure they are managed, tracked, securely stored and backed up. The last thing you want is to have a machine die that has the only private key for your environment.
Compared to what?
They seem to be okay w/ only HTTP ports being open on the server (80, 443). They "found that open ports can lead to cyber claims".
"Cyber claims" sounds like someone who doesn't have a clue what they are talking about.
But yeah putting it behind some kind of VPN is advisable if anything because of all the driveby nuisance attacks on ipv4.
That's like saying that open bottles lead to alcoholism.
Indeed.
Runs counter to my understanding, I'd ask for clarification and find support material to show your approach is safer.
Treat it as a teaching moment for them
How else would you do it?
Wireguard and Telnet ;)