Enable the OpenSSH Service
Ensures the sshd.service (OpenSSH server) is enabled at boot and running, providing an encrypted, authenticated remote-administration channel.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
OpenSSH (sshd) provides the encrypted, authenticated remote-management channel that administrators and automation rely on. Unlike legacy protocols (telnet, rsh, FTP), SSH protects credentials and session data in transit, defending against interception and tampering on untrusted networks. If sshd is not enabled and running, either remote administration is impossible (operational risk: no recovery path on headless servers) or it has been replaced by an insecure alternative. For most servers, a working, enabled SSH daemon is a baseline requirement for secure manageability, which is why NIST SC-8 and the STIGs mandate it.
What Pavois checks
Pavois reads the effective state of sshd.service from systemd, asserting it is both enabled (will start at boot) and running (active now). This catches a daemon that is installed but masked, failed to start, or only socket-activated-but-never-triggered, exactly the conditions that would silently leave a server unmanageable. A package or config-file check would report the SSH server 'present' while it is in fact down.
describe service('sshd.service') do
it { should be_enabled }
it { should be_running }
endHow to verify it is applied
Run systemctl is-enabled sshd.service and systemctl is-active sshd.service; expect enabled and active. Confirm it is accepting connections with ss -tlnp | grep :22 and validate the effective config with sshd -T | head (requires root).
Inspect & investigate
Authentication and session events are in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL); the daemon's own start/stop and errors are in journalctl -u sshd.service (or ssh.service on Debian/Ubuntu). systemctl show sshd.service -p ActiveState -p UnitFileState gives the state Pavois asserts. Confirm it is listening with ss -tlnp | grep :22.
Remediation
Pavois's harden plan acts on the service resource named sshd with actions enable then start: it sets the unit to start at boot and starts it immediately. Applied with pavois harden apply. Note: on Debian/Ubuntu the unit is ssh.service with an sshd.service alias.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | enable, start |
|---|---|
| name | sshd.service |
| resource | service |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Enabling and starting sshd opens TCP 22 to remote login, so this must be paired with a hardened SSH configuration: key-based auth, PermitRootLogin no, no password auth where possible, and a host firewall scoping who can reach the port. The greater operational risk is the opposite of this rule, never stop or disable sshd on a remote/headless host without an alternative access path (console, IPMI/iDRAC, cloud serial console), or you will lock yourself out. Before applying: ensure you are not depending on a currently-open session that a restart could drop, and that firewall rules will still permit your management network after sshd comes up.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| NIST | 3.1.13, CM-6(a), SC-8, SC-8(1), SC-8(2), SC-8(3), SC-8(4) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| DISA STIG | UBTU-22-255015, UBTU-24-100810 | direct | per OS STIG release | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.