My Sensible SSH + Firewall Setup on a Fresh VPS

0) SSH Tool

Before you secure your server, the first step is choosing an SSH client. While veterans are familiar with the command-line OpenSSH on Linux and macOS, or the classic PuTTY on Windows, modern tools can offer a much more polished experience.

For this guide, a fantastic option is Termius. It’s a modern, cross-platform SSH client that works on Windows, macOS, Linux, iOS, and Android. What sets it apart is its clean interface and host management, which is far more intuitive than manual config files. The free version includes an SFTP client for file transfers, port forwarding, and excellent mobile keyboard support.

Termius is especially appealing for students, as they can access premium features for free through the GitHub Student Developer Pack. This unlocks secure cloud-sync for your hosts and settings across all your devices, making it a powerful and convenient choice for managing your VPS from anywhere.

1) Safety net first

Keep your current SSH session open and test changes in a second terminal. If anything breaks, the original session lets you roll back.

# Sanity checks (Debian/Ubuntu-ish)
whoami && id
ssh -V
ss -ltnp | head

2) Create a user + keys (no passwords)

On your laptop (or iPad/desktop), create a modern key and copy it over.

# On your client
ssh-keygen -t ed25519 -C "me@laptop" -f ~/.ssh/id_vps_ed25519
ssh-copy-id -i ~/.ssh/id_vps_ed25519.pub root@YOUR.VPS.IP
# or manually:
# cat ~/.ssh/id_vps_ed25519.pub | ssh root@YOUR.VPS.IP 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys'

If you prefer a non-root user:

# On the VPS
adduser deploy
usermod -aG sudo deploy     # if you want sudo
mkdir -p ~deploy/.ssh && chown -R deploy:deploy ~deploy/.ssh
# From your client:
ssh-copy-id -i ~/.ssh/id_vps_ed25519.pub deploy@YOUR.VPS.IP

3) Harden sshd (keys only, no root login)

I like dropping a dedicated snippet so the distro’s default file stays readable:

# On the VPS (Debian/Ubuntu paths)
sudo tee /etc/ssh/sshd_config.d/01-hardening.conf >/dev/null <<'CONF'
# --- sensible hardening ---
Protocol 2
Port 22                      # you can change to a high port if you want; it's optional
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AllowUsers deploy            # or your chosen user

# Keep sessions healthy, drop zombies quickly
ClientAliveInterval 300
ClientAliveCountMax 2
LoginGraceTime 20
MaxAuthTries 3

# turn off rarely used stuff
X11Forwarding no
UseDNS no
Compression no
CONF

sudo sshd -t && sudo systemctl reload ssh  # (on some distros it's sshd)```

**Test in a new terminal**:

```bash
ssh -i ~/.ssh/id_vps_ed25519 deploy@YOUR.VPS.IP

If it works, you’re golden. If it doesn’t, don’t close your original session—fix and retry.

4) UFW: default deny, allow only what you need

sudo apt update && sudo apt install -y ufw

# defaults
sudo ufw default deny incoming
sudo ufw default allow outgoing

# allow SSH (adjust if you changed the port)
sudo ufw allow 22/tcp comment 'SSH'

# optional: rate-limit SSH against brute-force
sudo ufw limit 22/tcp

# optionally allow your own IP only (replace with your real IP)
# sudo ufw allow from 203.0.113.42 to any port 22 proto tcp

# web stuff
sudo ufw allow 80,443/tcp comment 'HTTP/HTTPS'

sudo ufw enable
sudo ufw status verbose

Tip: if you allowlist your home/office IP, keep a fallback path (VPN, a second IP, or VPS console) in case your IP changes.

5) (Optional) Tiny fail2ban

sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.local >/dev/null <<'JAIL'
[sshd]
enabled  = true
port     = 22
maxretry = 5
findtime = 10m
bantime  = 1h
JAIL
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

6) Nice client config

# ~/.ssh/config
Host my-vps
  HostName YOUR.VPS.IP
  User deploy
  IdentityFile ~/.ssh/id_vps_ed25519
  ServerAliveInterval 30
  ServerAliveCountMax 3
  StrictHostKeyChecking accept-new

Connect with ssh my-vps.

7) Quick rollback plan

• Still have your original SSH session? Undo the last change and systemctl reload ssh.
• Totally locked out? Use your provider’s web console, revert the snippet (or flip PasswordAuthentication yes temporarily), fix keys, and re-harden.

That’s it. Quiet logs, fewer bots, no drama.