Secure Ubuntu Server: Fail2ban, UFW & SSH Keys | Remote

Stop open SSH ports and noisy brute-force attempts on your Ubuntu server—we configure Fail2ban, UFW, and SSH key authentication remotely for production hosts worldwide. Ideal for operators who need a hardened baseline without guessing firewall rules that lock them out.

What You'll Get

• UFW baseline firewall - Default-deny inbound, explicit allow only for SSH, HTTP/HTTPS, and services you actually run, with IPv4/IPv6 parity checked.
• Fail2ban intrusion jails - SSH and optional nginx/apache jails with sensible ban times, findtime, and maxretry tuned to real attack patterns—not stock defaults that thrash legitimate traffic.
• SSH key-only access - Ed25519 (or RSA 4096 where required) keys installed, PasswordAuthentication and root password login disabled after live verification.
• sshd_config hardening pass - PermitRootLogin, MaxAuthTries, LoginGraceTime, and unused protocol options reviewed against your access model.
• Rollback & lockout safety - Secondary access path or console note before cutting password auth; we never leave you locked out of a sole cloud host.
• Plain-English runbook - Commands used, ports opened, ban unban how-to, and what to change when you add a new service.

Serving Remote & surrounds

Delivery is remote-first worldwide for Ubuntu on VPS, bare metal, and cloud images used by distributed teams. We specialise in the pattern Australian and APAC operators hit most: a single production box running Docker, WordPress, or a small API that suddenly shows thousands of failed sshd attempts after a public IP change. Seasonal spikes—end-of-financial-year launches, telehealth campaign weeks, student-term LMS traffic—often coincide with fresh VMs that still ship password SSH open to the world.

• SaaS and product teams on DigitalOcean, Linode, AWS Lightsail, or Hetzner needing a one-box security baseline before go-live
• Clinics and education providers hosting patient or student portals who must show firewall and fail2ban evidence for basic compliance hygiene
• Available remotely worldwide; on-site console help where practical if you already have datacentre or office rack access

How We Work

1. Step 1: Reach Out - Share OS version (Ubuntu 20.04/22.04/24.04), how you log in today, public ports in use, and whether you have cloud console/VNC as a backup path. We listen first—no generic checklist dump.
2. Step 2: Tailored Plan - Fixed quote for the hardening scope: UFW only, Fail2ban+SSH keys, or full stack plus optional web jails. You get clear out-of-scope notes (e.g. WAF, SELinux/AppArmor policy design) before we start.
3. Step 3: We Deliver - Scheduled remote session: package install, config, live SSH key test from your workstation, then disable password auth. We watch auth.log and ufw status during cutover.
4. Step 4: Confirm & Follow-up - You confirm login with keys only; we leave unban commands, jail status checks, and optional maintenance if you add services later.

Common Issues & How to Fix Them

These are failure modes we see repeatedly on Ubuntu hosts that look “secured” after a rushed tutorial—each with safe checks you can run before calling us in.

UFW enabled but IPv6 still wide open (or SSH drops on reboot)

Hosts with AAAA records or dual-stack clouds often get IPv4 rules only; attackers (and your own IPv6 path) bypass the wall. Or ALLOW rules were never made permanent and vanish after reboot, cutting remote admin.

1. Step 1: Run sudo ufw status verbose and ip -6 addr; confirm whether IPV6=yes in /etc/default/ufw and that status shows both v4 and v6 policies.
2. Step 2: If IPv6 is live, set IPV6=yes, re-apply default deny incoming / allow outgoing, then ufw allow OpenSSH (or your custom SSH port) before ufw enable. Prefer app profiles or explicit proto/port over blanket allow any.
3. Step 3: Reboot in a maintenance window or use cloud console; verify ufw status numbered still lists SSH and that you can connect on both stacks if you use them.

Fail2ban installed but never bans (or bans your office NAT repeatedly)

Stock sshd jail watching the wrong log path after rsyslog/journald changes, or maxretry too low behind a shared corporate egress IP, produces either zero bans or lockouts of your whole team every morning.

1. Step 1: Check sudo fail2ban-client status sshd and journalctl -u ssh -n 50 (or /var/log/auth.log). Confirm backend = systemd vs file matches how Ubuntu logs sshd on your release.
2. Step 2: Tune findtime/maxretry/bantime in a local jail.d override; add ignoreip for your static office/VPN ranges. Restart fail2ban and avoid editing jail.conf directly so package upgrades do not wipe you.
3. Step 3: Trigger a controlled failed login from a test host, then confirm the IP appears in fail2ban-client status sshd and iptables/nft chains; unban with fail2ban-client set sshd unbanip x.x.x.x.

SSH keys added but password auth still works—or you lock yourself out

Authorized_keys permissions wrong (or keys dropped in the wrong user’s file), PasswordAuthentication left yes, and root still password-reachable. Or someone sets PasswordAuthentication no before proving key login from a second session.

1. Step 1: From a second terminal already connected, confirm ~/.ssh is 700, authorized_keys is 600, and ssh -i yourkey user@host works without a password prompt. Keep the existing session open.
2. Step 2: In sshd_config.d drop-in, set PasswordAuthentication no, KbdInteractiveAuthentication no, PermitRootLogin prohibit-password (or no), then sshd -t before systemctl reload ssh.
3. Step 3: Open a fresh connection with the key only; only then close the safety session. If login fails, use provider console to revert the drop-in—never rely on a single untested change.

When DIY is not enough (urgent, unsafe, recurring, or burning time), book Fixwebnode for direct professional support—no freelancers, bidding, or marketplace noise.

Why Choose Fixwebnode

We harden Ubuntu as the direct provider—same engineers who live in auth.log and nft/iptables chains on client production boxes, not a bid board. You get lockout-aware change control, configs that survive apt upgrades, and a handoff written for the next person on your team at 2 a.m.

• ✓ Production-safe order of operations: verify access paths before disabling passwords
• ✓ Jail and UFW rules matched to real services (SSH custom ports, Docker-published ports, reverse proxies)
• ✓ Remote worldwide delivery with optional follow-up when you expose a new service

Tools & Technologies

Ubuntu 20.04/22.04/24.04 LTS; OpenSSH; UFW and underlying iptables/nftables; Fail2ban with systemd backend; ssh-keygen Ed25519/RSA; journalctl and auth.log analysis; cloud vendor serial/VNC consoles (AWS, GCP, Azure, DigitalOcean, Linode, Hetzner); optional nginx/apache fail2ban filters; basic sshd_config.d drop-ins.

Perfect For

Founders and technical owners running a single Ubuntu API, agency staging box, or clinic portal who need brute-force and firewall hygiene before a launch or audit question. Also fits MSPs and internal IT who want a clean baseline on customer VPS instances without standing up a full SIEM on day one. Remote delivery worldwide; we work around your change window.

Ready to harden the host? Start at fixwebnode.com.au/contact-support or chat with us for a fixed-scope remote session.