In a world where spinning up a VPS takes minutes but compromising it can take seconds, one GitHub repository has quietly become essential reading for admins and devops who work with Linux. It’s “How To Secure A Linux Server”—a living, contributor-friendly guide that distills, in a single place, the practical steps required to harden a Linux server: from tightening SSH and rolling out a firewall, to deploying Fail2Ban or CrowdSec, enabling automatic security updates, wiring auditing and health reports, and even automating the whole thing with Ansible.
It’s not just a list of commands. The guide anchors each chapter in why a control matters, how it works at a high level, and what to watch out for. It calls out the gotchas that brick servers—keep a second SSH session open before you touch sshd_config; prepare console access with your cloud provider; snapshot before you begin—and takes seriously what many “copy/paste” hardening posts omit: outbound mail for alerts, recoverability, backups, and tested restores.
From a “secure enough” baseline to serious hardening—without losing your weekend
The scope is distribution-agnostic and tested on Debian; it translates cleanly to Ubuntu and other distros with light changes (packages, paths, services). The structure follows a logical arc: secure access, trim privileges, seal the network, detect abuse, and audit continuously. Highlights, chapter by chapter:
- SSH. Generate Ed25519 keys on the client (
ssh-keygen -t ed25519), copy the public key to the server (ssh-copy-id), then disable password logins and root SSH. Create a group (e.g.,sshusers) and limit access withAllowGroups. Harden/etc/ssh/sshd_configwith modern Kex/Ciphers/MACs (Mozilla’s guidance), limit attempts (MaxAuthTries 2), and turn off unused forwardings. If you need 2FA, the guide uses libpam-google-authenticator (TOTP) and shows how to integrate it with PAM so password-based logins require a second factor. - Least privilege. Restrict sudo to a dedicated group (
sudousers) and require a password. Lock downsuso only members of a group (e.g.,suusers) can run it, adjusting/bin/supermissions accordingly. - Password policy. Enforce strength with
pam_pwquality(minimum length, character classes, repeat limits, “not in username” checks). - Time and
/proc. Keep NTP (orsystemd-timesyncd) running; time skew breaks auth and security checks. Mount/procwithhidepid=2to keep users from listing processes they don’t own (with notes about systemd compatibility on some distros). - Updates and alerts. On Debian, use unattended-upgrades for critical patches, apticron for “pending updates” notifications, and apt-listchanges to understand what will change. Crucially, configure outbound email (e.g., msmtp or exim4 with implicit TLS on port 465) so alerts actually reach your inbox.
- Firewall. With UFW as the human-friendly front end to iptables/nftables, deny incoming by default and—if you want a stricter posture—deny outgoing too, opening only what’s required: SSH, DNS (53), NTP (123), HTTP/HTTPS (for package installs and services), SMTP out for system mail, etc. The guide includes both strict and more permissive presets.
- Detection and response on the wire. Pair UFW with PSAD (reads kernel/iptables logs to detect port scans and suspicious traffic) or roll out CrowdSec (community-powered threat intel and bouncers for iptables/nftables). For the application plane, enable Fail2Ban with a ready-made SSH jail—and extend later to Nginx/Apache, databases, or reverse proxies.
- Audit and health. Run Lynis regularly for a prioritized security report and Logwatch for a daily email summary of system logs. The guide also includes AIDE (file integrity), rkhunter/chkrootkit (rootkit detection), and ClamAV (on-demand/scheduled scanning).
- Logging and rotation. Pull iptables logs into a dedicated file via rsyslog (using a prefix like
[IPTABLES]) and logrotate to avoid filling disks. - Modern crypto for SSH. Purge Diffie–Hellman moduli smaller than 3.072 bits in
/etc/ssh/moduli, a common miss in older images. - Application sandboxing. If your server doubles as a desktop or runs browsers/mail clients, the guide shows Firejail profiles to isolate those apps.
- Automation. An Ansible sibling repo reproduces hardening tasks across hosts. The author warns—edit variables to fit your setup, read tasks before applying, and ensure emergency access (cloud console) in case you misconfigure SSH.
Beyond the checklist, the value is prioritization and safety rails. Read each section before you apply it. Document distro differences. Never paste blindly.
A “secure baseline” in 30 minutes—and serious hardening in 1–2 hours
The appeal here is that you can start today. With 30–60 minutes, most admins can build a “minimum viable security” baseline—which you can expand later:
- SSH keys only, no passwords, no root, access restricted to a group.
- UFW enforced: defaults deny, open only what you need (don’t forget HTTP/HTTPS for package installs).
- Fail2Ban watching SSH.
- Unattended-upgrades and email alerts.
- Lynis for a first gap report and fast wins.
With another 1–2 hours, layer in CrowdSec or PSAD, daily Logwatch, hidepid=2 on /proc, pam_pwquality, the DH moduli cleanup, and a first pass at AIDE. If you manage more than a couple of servers, the guide’s Ansible route makes the outcome repeatable and idempotent.
How it avoids the usual foot-guns
A seasoned admin will recognize the failure modes this guide steers you around:
- Editing
sshd_configand restarting without a second live session. - Denying all outgoing traffic via UFW and forgetting DNS/NTP/HTTP(S)—bye-bye
apt. - Enabling MFA with no provider console access or emergency codes.
- Flipping
PasswordAuthentication nobefore you copy the public key.
By stating them plainly, the repo lowers the “accidental lockout” risk when you tighten a live VPS.
Who it’s for, and where it stops
The target audience is sysadmins, developers with VPSs, and anyone running self-hosted services (blogs, shops, proxies, homelabs). The approach is distro-agnostic and thoroughly Debian-tested.
How far does it go? It gets you to a solid baseline for internet-exposed hosts. For business-critical production (strict SLAs, regulated data), the guidance is to layer on CIS Benchmarks, formal audit regimes, observability (metrics/logs), tested backups and restores, and a documented recovery plan. The repo also includes OSSEC-HIDS if you need deeper host intrusion detection.
A keeper for your bookmarks (and your runbooks)
If you run servers, the hardest part isn’t knowing what to do—it’s having everything in one place, up-to-date, and with context. That’s the gap this guide closes: structure, rationale, copy-ready snippets, and, crucially, a prioritized task list you can start on today and build on safely.
For teams and freelancers, it standardizes hardening, makes it Ansible-driven, and documents controls clearly. For newcomers, it teaches security by doing. For veterans, it’s a living checklist that prevents omissions and captures helpful shortcuts.
Frequently asked questions
Can I run Fail2Ban and CrowdSec together, and what’s the benefit of each?
Yes. Fail2Ban parses application logs (SSH, Nginx, etc.) and bans IPs based on local patterns (e.g., repeated failures). CrowdSec does similar detection but shares threat intel with the community, shipping a curated blocklist to all users. A common pattern is Fail2Ban for your specific local services and CrowdSec to pre-empt known bad IPs at scale.
What’s the minimum I should do on a fresh VPS to avoid obvious exposure?
Use SSH keys only, disable root SSH, enable UFW (defaults deny; open only what you need), install Fail2Ban for SSH, enable unattended security updates with email alerts, and run Lynis for a first hardening report. You can reach that baseline in 30–60 minutes.
When does it make sense to automate with Ansible instead of configuring by hand?
As soon as you manage more than a couple of servers or repeat this often. The guide links Ansible playbooks that apply the SSH/UFW/Fail2Ban/updates stack. With Ansible you gain idempotence, speed, and consistency, and you reduce the risk of human error.
Why does the guide insist on outbound email if this is “just host security”?
Because alerts without delivery are worthless. An unattended upgrade that fails, a Fail2Ban ban you should know about, a Logwatch error summary, or a Lynis finding won’t help if nobody sees it. Configure msmtp or exim4 (implicit TLS on 465) early, and confirm messages hit your inbox.
Sources
- GitHub – How To Secure A Linux Server (An evolving how-to guide for securing a Linux server): https://github.com/imthenachoman/How-To-Secure-A-Linux-Server
- Mozilla – OpenSSH security guidelines (modern KEX/ciphers/MACs): https://infosec.mozilla.org/guidelines/openssh/
- Debian – Unattended-Upgrades (automatic security patching): https://wiki.debian.org/UnattendedUpgrades
- CrowdSec (community-driven detection and bouncers): https://www.crowdsec.net/
- CISOFY – Lynis (host-based security auditing): https://cisofy.com/lynis/
The repository includes further references (CIS Benchmarks, Fail2Ban, PSAD, AIDE, rkhunter, chkrootkit, Logwatch, Firejail, OSSEC) worth exploring once your secure baseline is in place.
