Episode 40 — Linux Hardening: SSH, PAM, and Auditd
In Episode Forty, titled “Linux Hardening: S S H, P A M, Audit Concepts,” we frame hardening as the discipline of reducing opportunities while increasing clarity. Systems rarely fall because of a single exotic flaw; they falter when small, permissive defaults accumulate into broad, fuzzy trust. Hardening reverses that drift by making access explicit, shrinking the surface area, and recording what matters so operations can explain decisions after the fact. The aim is not to make computers unpleasant to use but to ensure every privilege is both necessary and observable. When controls are deliberate and their effects are understandable, defenders gain the calm confidence that comes from predictability.
Strong environments begin with a spare accounts philosophy, because identity is the front door to every other control. Only purposeful accounts should exist, named in a way that reveals ownership, with disabled shells for non-interactive identities and locked logon paths where interaction is unnecessary. Default or vendor-supplied users must be removed or deactivated, and service identities should be scoped to the smallest set of files and actions they truly need. Groups carry meaning too; a tidy set of project or role groups beats sprawling, historical memberships that no one remembers approving. When presence is minimal and purposeful, the attack surface shrinks before a single firewall rule is written.
Remote administration hinges on the Secure Shell protocol, spelled S S H on first mention, whose objectives are confidentiality, integrity, and tight control of who can present a terminal at your doorstep. Configuration favors known ciphers and message authentication codes, host key algorithms with modern strength, and explicit protocol versions to prevent silent downgrade. Server identity must be pinned through host keys so clients recognize the machine they expect, and administrators should publish fingerprints through trusted channels rather than training users to click through warnings. Rate limits, connection throttles, and banners that communicate acceptable use round out the edges so brute force feels like pushing through wet cement. A locked-down S S H posture swaps guesswork for clearly defined gates.
Authentication is most defensible when private keys replace passwords, because a secret never typed is a secret that cannot be phished or keylogged. Key pairs stored with secure permissions, encrypted with passphrases, and optionally backed by hardware tokens add a second wall between theft and use. Servers should disable password authentication entirely once keys are deployed, enforcing public-key checks with restricted options such as forced commands or subsystem constraints for narrowly scoped roles. Authorized keys files deserve the same hygiene as code—versioned, reviewed, and rotated—because stale access is indistinguishable from unintended access. Where keys are managed centrally, revocation becomes a routine control rather than a scramble.
Sessions deserve boundaries that reflect human work and operational risk, which is why time-based controls and clear presentation matter. Idle timeouts log users out after periods of inactivity, curbing the window for shoulder surfing or unattended terminals, while login banners communicate policy and consent in unambiguous language. Per-connection limits and client keepalive tuning prevent orphaned sessions from lingering until a periodic cleanup happens to notice them. Command logging via approved mechanisms—never by brittle shell wrappers—captures activity without invading privacy beyond legitimate oversight. A session that begins with clear terms and ends on schedule leaves little room for ambiguity.
Authorization sits one layer above authentication and should be implemented with groups and a well-considered sudo design rather than broad, permanent administrator shells. The safest day-to-day pattern is an unprivileged account that elevates specific commands under sudo, with rules that name the binaries permitted and the options allowed. Every elevation attempt should be timestamped and recorded with the invoking user, target command, and outcome, which turns privilege use into an auditable transaction. Splitting administrative responsibilities into role-specific groups—backups, package maintenance, service control—avoids handing every operator a skeleton key. Least privilege then becomes a routine practice, not an aspirational slogan.
The Pluggable Authentication Modules system, mentioned first as P A M, is the decision chain that ties identity proofing to policy. Each stack—auth, account, password, and session—evaluates a series of modules in order, with control flags that decide whether to continue, fail, or ignore based on the result. This composable model lets teams require multiple checks, enforce account lockouts, and run session setup steps without patching applications. Misordered stacks and permissive control flags are common sources of silent weakness, so configurations benefit from comments that explain intent and from test cases that exercise success and failure paths. When P A M is readable, authentication outcomes are reproducible.
Multi-factor authentication integrates at the P A M layer as well, and its effectiveness depends as much on user experience as on cryptography. Time-based one-time codes, push approvals, or hardware-backed assertions can supplement keys for especially sensitive systems, but prompts must be designed to resist fatigue and confusion. Clear messaging, rate limiting, and step-up policies for higher-risk actions strike a balance between friction and safety. Recovery flows matter just as much: break-glass procedures should be rare, isolated, and monitored so urgency does not become an unlogged shortcut. A good M F A posture raises the cost of misuse without turning routine administration into an obstacle course.
Filesystems quietly enforce many of the strongest hardening controls, especially where sensitive paths and mounts are concerned. System areas should be owned narrowly with restrictive permissions, configuration directories should avoid group writability, and logs must be protected from casual modification. Mount options such as noexec, nosuid, and nodev on temporary or shared locations remove entire classes of escalation, while separate partitions for /var, /tmp, or application data prevent growth in one area from starving the whole system. Auditing which files can change at runtime reveals the difference between desired drift and suspicious mutation. When storage layout reflects trust boundaries, containment happens by default.
Kernel exposure is another place where minimalism pays dividends, because every enabled module is a potential extension of attack surface. Systems that do not require a capability should blacklist or avoid loading its module, and environments with predictable workloads can pin known-good sets at boot. Reducing interfaces—disabling unused network protocols, trimming debug features, and narrowing perf introspection—makes exploitation harder and detection clearer. Firmware and microcode updates belong to hardening as well, since a modern kernel paired with stale firmware is a mismatched defense. The operating system cannot protect what the kernel never needed to expose.
Selecting which events to capture is the art that keeps signal high and noise low. High-value actions include sudo invocations, failed and successful logins, modifications to security policies, starts and stops of critical services, and reads or writes on guarded directories. Capturing command arguments and return codes, within privacy and legal bounds, turns vague activity into actionable context. Periodic review of event volume and investigative utility prevents the audit trail from bloating into a liability. When every recorded item helps answer a likely question, analysis becomes faster and less error-prone.
Review cadence ties the whole system together, because controls that are never examined decay into theater. Scheduled checks of S S H configuration, P A M stacks, sudo rules, and mount options catch drift before attackers find it, and change validation ensures that updates move posture in the intended direction. Playbooks that define what to test, how to test it, and how to roll back reduce the stress of maintenance windows and shorten outages when surprises occur. Pairing reviews with small, frequent changes lowers risk compared to episodic, sweeping overhauls. Hardening then becomes a steady habit rather than a periodic campaign.
Deliberate controls and understandable outcomes are the hallmarks of a hardened Linux host. Identities exist only when they serve a purpose, remote access is encrypted and scoped, elevation is narrow and recorded, and the filesystem and kernel reveal as little as necessary. Auditing speaks clearly because selection was thoughtful, clocks agree, and storage keeps history within reach. None of this is glamorous, but it is the quiet craft that keeps operations resilient. When every control can be explained in a sentence and verified in a minute, you have turned hardening from folklore into engineering.
