# How-To-Secure-A-Linux-Server: a hardening checklist you read, not install > imthenachoman's guide is a long Markdown walkthrough of Linux server hardening, from SSH keys to UFW and Fail2Ban. It is a document, not a tool, and its value depends on how carefully you follow it. **imthenachoman/How-To-Secure-A-Linux-Server** — An evolving how-to guide for securing a Linux server. - Repository: https://github.com/imthenachoman/How-To-Secure-A-Linux-Server - Stars: 31,688 · Forks: 2,139 - Language: Unknown - License: CC-BY-SA-4.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/imthenachoman-how-to-secure-a-linux-server ## A guide for the person who owns one server, not a fleet The problem this project addresses is not a missing tool. It is that hardening advice is scattered across hundreds of blog posts, each covering a different slice, each assuming a different distribution. The README says exactly that: the author kept notes while researching a Debian build and realised the notes amounted to a guide. The stated objective is to teach you how to secure a Linux server and, in the author's words, to "also teach you a little about security and why it matters". That framing sets the audience. This is for the administrator of a small number of machines who wants to work through hardening in a deliberate order and understand why each step exists. It is not written for a platform team managing hundreds of hosts, and it does not pretend to be. The README's own use-case section exists precisely because the author's setup is narrow, and the guide is honest that other setups will differ. The scope is broad on purpose. The table of contents runs from SSH key management and 2FA through sudo and su restrictions, FireJail sandboxing, NTP, /proc hardening, password policy, automatic security updates, UFW, PSAD, Fail2Ban and CrowdSec, then into auditing with AIDE, ClamAV, rkhunter, chkrootkit, logwatch, ss, Lynis and OSSEC. Several of those entries carry a WIP marker, which the README does not expand on. Treat any WIP section as a starting point rather than a finished procedure. ## The repository is four files, and that is the whole mechanism There is no runtime here. The top level of the repository contains LICENSE.txt, README.md, linux-kernel-sysctl-hardening.md and nginx.md. The README is the guide; the other two Markdown files are supplementary material on kernel sysctl hardening and on nginx. There is no package, no binary, no install script and no configuration schema. The data flow is therefore entirely human. You read a section, you edit a file on your server such as /etc/ssh/sshd_config or a sudoers drop-in, you reload the relevant service, and you verify the result. The guide's value is in the ordering and the explanations attached to each step, not in automation. The README even has a section titled "Editing Configuration Files - For The Lazy", which acknowledges that the reader is expected to be typing these changes by hand. One concrete consequence: nothing in the repository enforces that you did a step correctly. If you mistype a sudoers rule or lock yourself out of SSH, the guide cannot detect it. The README addresses this indirectly with a note before the SSH changes section, warning you to be careful before modifying SSH configuration. That warning is the closest thing to a safety net the project provides. The one automation path the README points to is external. It links to How-To-Secure-A-Linux-Server-With-Ansible by moltenbit, a separate repository that turns the guide into Ansible playbooks. That is a different project with its own maintenance, and the guide does not guarantee the two stay in sync. ## Installing it: there is nothing to install Because the project is documentation, there is no installation step. The README does not give a package name, a version, a port or an environment variable, and it does not tell you to run an installer. What you do instead is read the guide and apply its steps to a server you already have. The practical starting point is to clone the repository so you have the full text, including the supplementary files that are not reproduced in the README excerpt. The command below is a plain git clone of the default branch, which the repository metadata identifies as master. ```bash git clone https://github.com/imthenachoman/How-To-Secure-A-Linux-Server.git cd How-To-Secure-A-Linux-Server ls ``` After that you should see LICENSE.txt, README.md, linux-kernel-sysctl-hardening.md and nginx.md. Open README.md in a Markdown viewer or on GitHub and work from the table of contents. The guide's first real use is the SSH work, because that is the section the table of contents places first among the technical material. It covers creating SSH public and private keys, creating a group for AllowGroups, securing /etc/ssh/sshd_config, removing short Diffie-Hellman keys, and adding 2FA or MFA. A typical first action is editing the SSH daemon configuration on the server, then validating and reloading it. The exact keys and values belong in the guide's own section, and you should copy them from there rather than from a summary, because the correct values depend on your OpenSSH version. ```bash sudo sshd -t sudo systemctl reload sshd ``` The first command tests the configuration for syntax errors before you apply it. The second reloads the daemon. If sshd -t reports nothing, the file parsed. Keep your existing session open until you have confirmed a new login works, because reloading sshd does not terminate established connections. For the network layer, the guide covers UFW as its firewall of choice, with a dedicated section on Docker and UFW, and separate sections on PSAD, Fail2Ban and CrowdSec for intrusion detection and prevention. Those are installed with your distribution's package manager, and the guide walks through the configuration for each. ## Where the guide stops being enough The most obvious limitation is that a document cannot verify itself. Every step in this guide is a manual edit, and manual edits drift. If you rebuild the server in six months, or if a colleague provisions a second one, nothing in the repository reproduces the hardening you applied. The README's own answer to this is to point at the external Ansible playbook project, which means the reproducibility story lives outside this repository and outside its control. A second limitation is distribution specificity. The README describes the guide as growing out of a Debian build. Package names, service unit names, file paths and default configuration values differ across Debian, Ubuntu, RHEL-family distributions and Arch. The guide covers the concepts, but a command that works on Debian may need translation elsewhere, and the README does not provide a per-distribution matrix. The WIP markers are a third signal. Several auditing sections, including AIDE, ClamAV, rkhunter and chkrootkit, are marked as work in progress, and the entropy pool section carries the same marker. A WIP section is not a failure, but it means you should not treat the guide as authoritative for those topics yet. If file integrity monitoring is your primary goal, the guide gives you the tool names and a starting configuration, not a finished procedure. Finally, this is the wrong tool if you need an auditable control framework. There is no mapping to CIS benchmarks, no scoring, and no evidence collection. Lynis, which the guide covers, produces a hardening index, but that is Lynis reporting, not this project. ## Compared with an Ansible role or a benchmark scanner The closest alternatives fall into two groups, and they differ from this guide in approach rather than in topic. An Ansible role or playbook, including the How-To-Secure-A-Linux-Server-With-Ansible project the README links to, encodes the same hardening steps as executable tasks. The difference is idempotence: you run the playbook against a host, and re-running it converges the host back to the desired state. This guide gives you the knowledge to write or review those tasks, but it does not converge anything. If your problem is "I have twenty servers and I need them all configured the same way", the playbook is the right shape of solution and the guide is background reading. A benchmark scanner such as Lynis takes the opposite approach: it inspects a running system and reports findings, rather than telling you what to change. The guide actually includes a Lynis section, which is a sensible combination, because the scanner tells you where you stand and the guide tells you what to do about it. The trade-off is that a scanner gives you a score and a list, not an explanation of why a setting matters, and the README is explicit that teaching the why is part of its objective. Neither alternative replaces the other two. A playbook without understanding is fragile when it breaks; a scanner without a remediation path produces a report nobody acts on. The guide's role is the middle layer. ## Licence, maintenance and what upgrading looks like The repository is licensed CC-BY-SA-4.0, which the README displays with the Creative Commons badge and a link to the licence. That is a content licence, not a software licence, which fits a documentation project. In practical terms, CC-BY-SA permits sharing and adaptation with attribution and under the same licence. If you fork the guide, translate it, or republish sections internally, the share-alike condition travels with the material. The authoritative text is LICENSE.txt in the repository, and this is a description of what the licence identifier means, not legal advice. Maintenance is straightforward to characterise. The repository is not archived, and the last push was on 2026-09-07, which is recent. The README describes the guide as evolving and invites contributions, and the table of contents includes a Contributing section. There are no retrieved releases, which is expected for a documentation repository. Upgrading has no version numbers to track. You pull the repository and re-read the sections that changed, then decide whether your server still matches. The cost is in re-verification, not in a migration. If you have applied the guide by hand, a change to a recommended sshd_config directive means you need to find every host where you applied the old value. That is the same drift problem described above, and it is the strongest argument for pairing this guide with the Ansible playbook if you run more than a couple of machines. ## Conclusion Adopt this guide if you run a small number of Linux servers yourself and want a single ordered checklist for SSH, sudo, firewalling and auditing; the README states it was written from notes taken during a Debian build, so treat Debian-family paths as the default and verify every command against your own distribution. Do not adopt it as a substitute for a configuration management system or for a compliance framework, and do not expect installable artifacts, because the repository holds four files and no code. Before you start, read the Ansible playbook repository it links to, check the licence text in LICENSE.txt, and confirm that the guide's current state still matches your distribution's defaults for sshd_config and sudoers. ## FAQ ### Is Linux safer for banking? The guide does not compare Linux with other operating systems for banking. Its introduction argues that any device in the public domain becomes a target, and that without good security you may never know your server was compromised. The scope it sets for itself is how to secure a Linux server, not which platform is safer. ### How to stay secure on Linux? The README's answer is to work through the guide's sections in order, starting with the SSH Server material on keys, AllowGroups, /etc/ssh/sshd_config and 2FA, then the basics such as sudo and su restrictions, then the network layer with UFW, PSAD, Fail2Ban and CrowdSec. Each step is a manual change you apply and verify on your own server. ### What makes Linux more secure than Windows? The guide does not make this comparison. The README says the question of why good security matters is a heavy topic that is out of scope, and it advises researching it separately rather than answering it. What the guide offers instead is the concrete list of steps for securing a Linux server. ### How can I hardening my Linux server for security? Follow the table of contents from top to bottom, beginning with the SSH Server section, which covers SSH public and private keys, creating a group for AllowGroups, securing /etc/ssh/sshd_config, removing short Diffie-Hellman keys and adding 2FA or MFA. The guide is documentation, so every step is an edit you make on your own server rather than an installer you run. ## Sources - [imthenachoman/How-To-Secure-A-Linux-Server on GitHub](https://github.com/imthenachoman/How-To-Secure-A-Linux-Server) - [Issues](https://github.com/imthenachoman/How-To-Secure-A-Linux-Server/issues) - [License: CC-BY-SA-4.0](https://github.com/imthenachoman/How-To-Secure-A-Linux-Server/blob/master/LICENSE) - [README](https://github.com/imthenachoman/How-To-Secure-A-Linux-Server/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/imthenachoman-how-to-secure-a-linux-server