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