11–20 of 41 posts
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.
How else would you do it?
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".
But yeah putting it behind some kind of VPN is advisable if anything because of all the driveby nuisance attacks on ipv4.
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…
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?
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…
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…
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:
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-...
> 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…
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.