Secure SSH and firewall access on an Ubuntu VPS

The classic remote-hardening accident is locking the door while you’re still outside: the firewall comes up before SSH is allowed through it, and the server is now secure against everyone — including you. Every step here follows one rule: keep an authenticated session open and confirm provider-console access before changing SSH or firewall rules.

1. Create a named administrator

Use an individual account rather than shared root access:

sudo adduser alice
sudo usermod -aG sudo alice

Administrators should use separate accounts so actions can be attributed and access can be revoked cleanly.

2. Add a public key

Generate a modern key on the local computer if needed, protect it with a passphrase, and copy only the public key to the server:

ssh-keygen -t ed25519
ssh-copy-id alice@203.0.113.10

Test a new session and sudo. Store a backup key or documented recovery path according to organizational policy.

3. Use a configuration snippet

Place local policy in /etc/ssh/sshd_config.d/10-hardening.conf:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

If the server uses a required authentication system, adapt the settings rather than copying them blindly. Ubuntu notes that snippet values may override the main file.

Validate and inspect effective settings:

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication'

Restart the service only after validation, then test another new session.

4. Configure UFW before enabling it

Confirm the actual listening port:

sudo ss -lntp | grep ssh

Allow that port, then add only required public services:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --dry-run enable
sudo ufw enable
sudo ufw status numbered

Use source restrictions for administrative services when stable addresses or a private network are available. Never publish database ports merely for convenience.

5. Add defense in depth

Keep OpenSSH and the OS updated. Review authentication logs, remove unused accounts and keys, limit sudo, and use network-level firewall controls when the provider offers them. Consider rate limiting or an intrusion-prevention tool only after key authentication and access ownership are correct.

Changing the SSH port can reduce automated log noise, but scanners can still find it. Do not treat a nonstandard port as authentication.

6. Document and test recovery

Record console access, authorized keys, firewall policy, and the process for replacing a lost key. Test recovery before an incident, including how to mount a rescue environment or use provider console access.

Sources and further reading

• Ubuntu Server: OpenSSH
• Ubuntu Server: UFW firewall