Enable SSH Warning Banner (issue.net)
Configures sshd to present a legal warning banner to remote clients before login by setting Banner /etc/issue.net.
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
A pre-authentication banner reinforces policy awareness during login and supports possible legal action against intruders by removing any ambiguity about unauthorized access. For network logins the dedicated /etc/issue.net file is used so the message shown to remote SSH clients can differ from the local console /etc/issue. (Systems whose ownership should stay non-obvious can use a banner that avoids easy attribution.)
What Pavois checks
Pavois reads the effective banner value from sshd -T, the daemon's resolved configuration. A scan of /etc/ssh/sshd_config could miss a value set in an Included drop-in under /etc/ssh/sshd_config.d/ (Ubuntu/Debian ship several), sshd -T reflects exactly which banner the running daemon presents to remote clients.
describe command('sshd -T') do
its('stdout') { should match(/^banner\s+\/etc\/issue\.net$/i) }
endHow to verify it is applied
Run sudo sshd -T | grep -i banner. The expected output is banner /etc/issue.net. You can also open a fresh ssh connection from another host and confirm the banner text appears before the password prompt.
Inspect & investigate
Banner presentation is not logged directly, but the surrounding connection and authentication events are recorded by sshd in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL family); follow with journalctl -u ssh -f (or -u sshd). The banner content lives in /etc/issue.net.
Remediation
No automated remediation is defined for this rule (remediation is empty), so it must be applied manually: set Banner /etc/issue.net in /etc/ssh/sshd_config (or a drop-in in /etc/ssh/sshd_config.d/), put the approved warning text in /etc/issue.net, validate with sshd -t, then reload the service (systemctl reload ssh / sshd).
Pavois applies this with its own harden engine, the plan below, not a shell script:
| directive | Banner |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | /etc/issue.net |
| verify | sshd -t -f %{path} |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Without a network banner, remote users get no legal/usage notice and prosecuting intruders is harder; the gap is compliance-oriented rather than a direct technical exposure. Applying it is low-risk. Precaution: keep /etc/issue.net generic, avoid hostname, OS version, or other reconnaissance-useful details, and note that some clients only display the banner in interactive sessions. Reloading sshd (not restarting) keeps existing sessions alive, so there is no lockout risk.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 5.1.5, 5.1.8, 5.1.7 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.9, AC-17(a), AC-8(a), AC-8(c), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| DISA STIG | UBTU-22-255020, UBTU-24-200640 | 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.