Ask HN: Is Connecting via SSH Risky?

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.

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.

> 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-...

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.

> I was recently informed that a client I work with considers that a legal risk.

What's their alternative? I guess you could install frontpage extensions to manage content, but Microsoft's contractor for FrontPage extensions on unix and similar took the downloads down[1], so that's a lot of work. :P

[1] http://www.rtr.com/fpsupport/fp2002sr1_download.htm

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.

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

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.

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?

How else would you do it?