Do Not Allow SSH Environment Options
Prevents users from injecting environment variables at login by setting PermitUserEnvironment no in sshd.
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
When PermitUserEnvironment is enabled, sshd reads ~/.ssh/environment and environment= options in authorized_keys, letting a user set variables such as LD_PRELOAD or PATH before their shell starts. This can be used to bypass access restrictions, subvert PAM-driven controls, or load attacker-controlled libraries, effectively a local privilege-escalation and policy-evasion vector. Setting it to no ensures the user environment is built solely from the system configuration.
What Pavois checks
Pavois reads the effective directive from sshd -T, the daemon's fully resolved configuration. A file-based scan of /etc/ssh/sshd_config would miss the value when it is set in an Included drop-in (/etc/ssh/sshd_config.d/*.conf) or in a Match block, sshd -T shows exactly what the running daemon enforces.
describe command('sshd -T') do
its('stdout') { should match(/^permituserenvironment\s+no$/i) }
endHow to verify it is applied
Run sudo sshd -T | grep -i permituserenvironment. The expected output is permituserenvironment no.
Inspect & investigate
Login and shell-setup events for sshd are recorded in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL family); follow them with journalctl -u ssh -f (or -u sshd). Refused environment-option processing is visible there during authentication.
Remediation
pavois harden apply writes the sshd_setting directive permituserenvironment with value no into a managed drop-in, validates it with sshd -t -f %{path}, then notifies a reload of the ssh service so the change applies without interrupting active connections.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| directive | permituserenvironment |
|---|---|
| notify | action: reload, service: ssh.service |
| resource | sshd_setting |
| value | no |
| verify | sshd -t -f %{path} |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Leaving PermitUserEnvironment enabled is a privilege-escalation and policy-bypass risk, as untrusted users can preset critical variables. Disabling it is the safe default and almost never breaks legitimate use. Precaution: if any service or automation relies on per-user ~/.ssh/environment or environment= entries in authorized_keys, move that configuration into the system-wide environment (e.g. /etc/environment, a PAM pam_env file, or the unit/service definition) before applying. The reload preserves your current SSH session, so there is no lockout risk.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 2.2.6, 5.1.21, 5.1.23 | direct | per OS, see the benchmark table | high |
| NIST | 3.1.12, AC-17(a), CM-6(a), CM-7(a), CM-7(b) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 2.2.6 | supporting | 4.0.1 | medium |
| DISA STIG | UBTU-22-255025, UBTU-24-300031 | 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.