Security Settings

Back to Server Setup · OS Hardening · Patch Management · Security Headers Checker

SSH key-based access, disabled root login, automatic security updates, and encryption for data at rest and in transit where applicable. These are the settings that do the most per minute spent, and none of them is the default.

1. Keys, Not Passwords

• Key-based authentication only, with password authentication switched off entirely. A password can be guessed at scale from anywhere; a key cannot. An internet-facing SSH port sees continuous credential-guessing traffic within hours of existing, and with passwords disabled none of it can succeed.
• Protect the private keys. A passphrase on the key, an agent for convenience, and a rule that keys are never shared between people — a shared key destroys the audit trail.
• Know how to revoke. Removing one person's access should be a change in one place, which in practice means keys distributed by configuration management or a central directory rather than appended by hand on each host.
• Rate-limit what remains. Tools that temporarily block repeated failures cut the noise in the logs substantially. This is hygiene rather than protection — disabled passwords are the actual control — but quieter logs make real events visible.

2. No Direct Root Login

Administrators log in as themselves and elevate. The reason is accountability: root is not a person, so a log entry saying root did something identifies nobody. Elevation should be restricted to the accounts that need it, granted to named individuals, and logged. It is worth granting the narrowest elevation that works rather than unrestricted access to everything — see user management and permissions.

One caution learned the hard way: verify the new access path works from a second, separate session before closing the one you already have. Locking yourself out of a remote server by tightening its access rules is a common and entirely avoidable outage.

3. Automatic Security Updates

Security patches applied weeks late are the most common route into a server, and manual patching slips whenever people are busy — which is exactly when it matters.

• Enable unattended security updates for the operating system. Security updates only, not every package: the aim is to close vulnerabilities without changing behaviour.
• Decide about reboots explicitly. Kernel updates need one to take effect, so either schedule a reboot window or use live patching. A patched kernel that has never been booted is not protecting anything.
• Feature and major-version upgrades stay manual, tested, and scheduled.
• Automation does not replace a process. Application dependencies, container images and firmware are outside it, and something still has to notice when an update fails — which is where patch management comes in.

4. Encryption, Where It Applies

• In transit, including internally. TLS on anything public is assumed; the gap is usually internal traffic — application to database, service to service — left in the clear because “the network is trusted”. Modern protocol versions only, with certificate renewal automated, because an expired certificate is a self-inflicted outage. Our security headers checker and certificate expiry checker cover the public side.
• At rest, where the threat is real. Full-disk encryption protects against hardware being removed or improperly disposed of. It does nothing against an attacker with access to a running system, so be clear about which risk is being addressed rather than treating it as general protection.
• Backups above all. Backups are copies of everything, often stored somewhere else, and they are frequently the least protected. Encrypt them, and keep the key somewhere that survives the failure you are protecting against — see backup and recovery.
• Answer the key question. Who holds the key, where the escrow copy is, and what happens if it is lost. Encryption is an excellent way to lose your own data.

5. Verify, Then Keep Verifying

Every setting here can be checked from outside or by a script, and all of them drift. We confirm at handover that passwords really are refused, root login really is denied, updates really are being applied, and TLS really is enforced — and we leave those checks behind as something that runs periodically rather than as a paragraph in a document.

What You Get

• Key-only SSH with a documented process for granting and revoking access.
• Named accounts with scoped elevation, and root login disabled.
• Unattended security updates with a stated reboot policy, and monitoring that they are working.
• TLS internally as well as externally, with automated certificate renewal.
• Encryption at rest where it addresses a real risk, with key custody documented.
• Automated verification of each of the above, so drift is visible.