Hardening Linux Servers: The Complete 2026 Checklist

In early 2026, attackers exploited a misconfigured SSH daemon on an exposed Ubuntu 24.04 server to pivot into a financial services network — the entry point was a root login left enabled after a rushed deployment. That breach cost the team three weeks of incident response. Most of the damage was preventable with a one-hour hardening pass.

This checklist covers what actually matters in 2026: SSH lockdown, privilege controls, and automated compliance scanning. Every step has a real command. No padding.

Step 1: Lock Down SSH Before Anything Else

SSH is still the most common initial access vector against Linux servers. Default configs are dangerously permissive. Run this audit first on any new box.

# On prod-web01.internal (192.0.2.10) — audit current SSH config
sshd -T | grep -E 'permitrootlogin|passwordauthentication|x11forwarding|permitemptypasswords|protocol'

Expected output on a stock Ubuntu 24.04 install:

permitrootlogin yes
passwordauthentication yes
x11forwarding yes
permitemptypasswords no
protocol 2

Two lines should alarm you immediately: permitrootlogin yes and passwordauthentication yes. Root login over SSH means an attacker who guesses or brutes credentials lands directly as UID 0. Password auth means they can try at all. Fix both in /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
AllowUsers deploy@192.0.2.0/24
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

The AllowUsers directive is underused. It restricts SSH access to the deploy user and only from your internal subnet — a lateral movement chokepoint attackers hate. Reload with systemctl reload sshd and verify with sshd -T again.

Step 2: Audit Privileged Access and SUID Binaries

Privilege escalation after initial access usually runs through one of three paths: a misconfigured sudo rule, a forgotten SUID binary, or a world-writable script in root’s cron. Check all three in under five minutes.

# Find SUID binaries — run as root on prod-app01.internal (192.0.2.15)
find / -perm -4000 -type f 2>/dev/null | sort

A clean 2026 Debian 12 server returns a short, predictable list:

/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/su
/usr/bin/sudo
/usr/bin/mount
/usr/bin/umount
/usr/lib/openssh/ssh-keysign
/usr/lib/dbus-1.0/dbus-daemon-launch-helper

If you see /usr/bin/python3, /usr/bin/vim, /usr/bin/find, or /usr/bin/nmap in that list, stop. Each of those is a trivial GTFOBins escalation path. Strip the SUID bit immediately:

chmod u-s /usr/bin/find

Next, audit sudo rules — this catches the classic misconfiguration where a developer account was given blanket NOPASSWD access and never removed:

grep -r 'NOPASSWD' /etc/sudoers /etc/sudoers.d/

/etc/sudoers.d/deploy: deploy ALL=(ALL) NOPASSWD: ALL

That single line means any process running as deploy — including a compromised web app — can become root without a password. Scope it tightly or remove it. If the user genuinely needs sudo, restrict it to specific commands:

deploy prod-app01 = (root) NOPASSWD: /usr/bin/systemctl restart nginx

Step 3: Run a CIS Benchmark Scan and Track Your Score

Lynis is a local security auditing tool — it checks your system against CIS benchmarks and hundreds of other controls, then gives you a hardening index score. It takes four minutes to run and shows you exactly what to fix next.

# Install and run Lynis on prod-db01.internal (192.0.2.20)
apt install lynis -y
lynis audit system --quick 2>/dev/null | tail -30

-[ Lynis 3.1.4 Results ]-

Hardening index : 58 [###########         ]
Tests performed : 264
Plugins enabled : 2

Components:
  - Firewall               [V]
  - Malware scanner        [X]
  - File integrity         [X]
  - Logging                [V]

Suggestions (23):
  * Enable process accounting [ACCT-9622]
  * Restrict access to /proc [PROC-3602]
  * Set umask in /etc/login.defs [AUTH-9328]
  * Consider hardening sysctl settings [KRNL-6000]
  * Install a file integrity tool (AIDE/Tripwire) [FINT-4350]

A score of 58 on a fresh server is typical and not acceptable for production. The suggestion codes are your roadmap. FINT-4350 — no file integrity monitoring — is the critical one. An attacker who modifies /etc/passwd or drops a backdoored library goes undetected without it. Install AIDE and initialize a baseline today:

apt install aide -y
aide --init
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Schedule a daily check via cron: 0 3 * * * /usr/bin/aide --check. Any deviation from the baseline triggers an alert. That’s your tripwire.

What To Do Now

Pick one server — your most exposed, internet-facing box — and run sshd -T | grep -E 'permitrootlogin|passwordauthentication' right now. If either returns yes, you have an open door. Fix the SSH config, reload the daemon, and schedule the Lynis scan for this week. One hour of work closes the attack paths that took down that financial services team for three weeks.