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.
Ask HN: Is Connecting via SSH Risky?
21–30 of 41 posts
Re: Ask HN: Is Connecting via SSH Risky?
#22No, 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.
Re: Ask HN: Is Connecting via SSH Risky?
#23Earlier quoted context omitted.
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…
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.
Re: Ask HN: Is Connecting via SSH Risky?
#24If 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?
Re: Ask HN: Is Connecting via SSH Risky?
#25If 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.
Re: Ask HN: Is Connecting via SSH Risky?
#26They 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 vu…
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?
Re: Ask HN: Is Connecting via SSH Risky?
#27> 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 use…
> 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.
Re: Ask HN: Is Connecting via SSH Risky?
#28Earlier quoted context omitted.
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.
Re: Ask HN: Is Connecting via SSH Risky?
#29SSH 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
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.
Re: Ask HN: Is Connecting via SSH Risky?
#30> 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 use…
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.