Small Cloud Server Hardening: SSH Keys, fail2ban, BBR

A small cloud server is often attacked within hours of going online. On my own low-cost ECS instance, the first thing I saw in the logs was repeated password-guessing against SSH. This short note records the three hardening steps I actually use, in the order I apply them, and the checks I run afterwards. Nothing here requires a paid security product.

1. SSH key login, and turn off password login

Generate a key pair on your own computer, copy only the public key to the server, and test that key login works before you change anything else. Then, in sshd_config, set PasswordAuthentication no and PubkeyAuthentication yes, and restart sshd. Keep your existing session open while you test a second login in a new window, so a mistake does not lock you out. I also change the default port only as a log-noise reducer, not as real security, and I restrict login to a normal user with sudo rather than root.

2. fail2ban for the brute-force noise that remains

Key-only login already stops password guessing from succeeding, but fail2ban still cuts the noise and the load. Install fail2ban, enable the sshd jail, and set a sensible ban time and retry limit, for example a few failed attempts within ten minutes. Check its status with fail2ban-client status sshd, and remember to whitelist your own office or home address if it is stable, otherwise you can ban yourself after a few typos.

3. BBR for a faster, steadier connection

On a small instance, TCP BBR often gives a visibly smoother experience than the default congestion control, especially on lossy or long-distance links. Enable it by setting net.core.default_qdisc to fq and net.ipv4.tcp_congestion_control to bbr, apply with sysctl, and verify that the congestion control in use is actually bbr. BBR is not a security control, but it belongs in the same first-hour checklist because it improves file transfers and interactive latency without extra cost.

Checks I run at the end

After these steps I verify three things: I can log in with the key and cannot log in with a password, fail2ban is running and has the sshd jail active, and the kernel reports bbr as the congestion control. I also enable automatic security updates and review the auth log once a week. Hardening is not a one-time task, but these three steps remove the most common, most automated attacks on a small server, and they take less than an hour to do carefully.