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