Update Login Banner

What the Linux login banner enforcer does

This Automox Worklet™ enforces a consistent login banner across every Linux endpoint in your fleet. The Worklet writes a standardized security warning to the local message-of-the-day file at /etc/motd, the pre-login banner at /etc/issue, and the network pre-login banner at /etc/issue.net. It then confirms that /etc/ssh/sshd_config contains an active Banner directive pointing to /etc/issue.net so SSH clients see the warning before the credential prompt.

Banner content already matching the configured warning is left untouched, so the policy is safe to run on a mixed fleet. When the Worklet does change a file, it sets ownership to root:root and applies 0644 permissions to match the CIS Benchmark recommendation. The evaluation phase is idempotent and the remediation phase exits non-zero when sshd_config is missing or the SSH service refuses to restart, so failures surface in Automox activity logs instead of going silent.

On hosts where the Banner directive is commented out, the Worklet uncomments the existing line rather than appending a duplicate. On hosts where the directive is absent, the Worklet appends a single Banner /etc/issue.net line at the end of sshd_config. The script then runs sshd -t to validate the configuration before issuing systemctl restart sshd, so a syntax error never takes a host offline.

Why enforce CIS 1.7.x login banner compliance

Login banners are a named control in CIS Benchmark 1.7.x for every major Linux distribution. CIS 1.7.1 requires a message-of-the-day file with no operating system or version disclosure. CIS 1.7.2 and 1.7.3 require pre-login banners at /etc/issue and /etc/issue.net. CIS 1.7.4 through 1.7.6 require those files to be owned by root with 0644 permissions. The same access-warning language is the basis for NIST 800-53 AC-8 (System Use Notification) and is referenced by SOC 2 CC6.1 audit criteria. An endpoint with a missing or default banner is a documented audit finding, not a stylistic preference.

The four banner artifacts drift in different ways. A package update on openssh-server overwrites /etc/issue.net with the distribution default, an admin loosens sshd_config to debug a connection issue and leaves Banner commented out, a fresh image ships without /etc/motd populated. The Worklet evaluates /etc/issue, /etc/issue.net, /etc/motd, and the matching Banner directive in sshd_config on every cycle, runs diff against the policy-defined warning text, and rewrites whichever files have drifted, so a missing banner is closed before it becomes a CIS 1.7.x or NIST AC-8 audit finding. You define the desired warning text once in the policy, and the enforcement loop holds the state in place across every server, container host, and developer workstation under management.

How Linux login banner enforcement works

1. Evaluation phase: The Worklet reads /etc/motd, /etc/issue, and /etc/issue.net and compares each file to the configured banner string. It checks the owner and group of all three files against root:root and the mode against 0644. It then scans /etc/ssh/sshd_config for a Banner directive that is uncommented and points to /etc/issue.net. If any file is missing, contains stale text, has wrong permissions, or the SSH Banner directive is absent or commented out, the endpoint is flagged non-compliant and remediation is scheduled.

2. Remediation phase: The Worklet writes the configured banner text to /etc/motd, /etc/issue, and /etc/issue.net, chowns each file to root:root, and chmods each to 0644. For sshd_config, the script uses sed to uncomment an existing Banner line when present, or appends Banner /etc/issue.net when absent. It runs sshd -t to validate the configuration, then issues systemctl restart sshd (or service ssh restart on SysV hosts) so the banner displays on the next SSH session. The remediation exits 0 on success and non-zero with a stderr message when sshd validation fails.

Login banner enforcement requirements

• Linux endpoint running RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, or Amazon Linux with OpenSSH installed

• Root or sudo privileges for the Automox agent (the default agent context already meets this)

• /etc/ssh/sshd_config present and writable; the Worklet uses sshd -t to validate before restarting

• systemd-based init (systemctl) or SysV init (service) available so the SSH daemon can be restarted after a configuration change

• Set the banner variable in evaluation.sh and remediation.sh to the exact warning text your security team approved; keep it free of OS or version strings to satisfy CIS 1.7.1

• FixNow compatible for immediate remediation through the Automox console when an auditor requests evidence on a tight deadline

Expected Linux endpoint state after banner enforcement

After the Worklet runs, /etc/motd, /etc/issue, and /etc/issue.net all contain the configured warning text, are owned by root:root, and carry 0644 permissions. The /etc/ssh/sshd_config file contains an active Banner /etc/issue.net directive with no leading hash. The SSH daemon has been restarted and is serving the banner on the next connection. Subsequent Automox policy runs report the endpoint as compliant without applying remediation again, because the evaluation phase finds every file already in the desired state.

Validate by opening a fresh SSH session to the endpoint from a workstation that has not authenticated recently; the banner from /etc/issue.net appears before the password prompt. Confirm console behavior on the host with cat /etc/issue and observe the banner at a tty login. For audit evidence, capture the output of stat -c '%U %G %a %n' /etc/motd /etc/issue /etc/issue.net and grep -E '^Banner' /etc/ssh/sshd_config, then store both alongside the Automox policy run identifier. The configuration survives reboot, kernel upgrade, and package update; only an administrator overwriting one of the four files will trigger non-compliance, at which point the next evaluation reads the changed file, sees the diff against the policy text, and the remediation pass rewrites the contents with the configured warning.