Disable GSSAPI Authentication
Forces GSSAPIAuthentication no so SSH does not offer the GSSAPI (typically Kerberos) authentication mechanism.
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
GSSAPI provides pluggable authentication (most often Kerberos) to applications. Exposing it through SSH widens the attack surface: it reaches the system's GSSAPI/Kerberos stack from the network and historically has been a source of pre-authentication vulnerabilities. On hosts that do not participate in a Kerberos realm, this mechanism is pure dead weight and should be disabled to keep the set of enabled auth methods minimal.
What Pavois checks
Pavois reads the effective value from sshd -T, after all Includes, drop-ins in /etc/ssh/sshd_config.d/ and Match blocks. On RHEL-family systems system-wide crypto policies inject SSH settings via includes, only the resolved sshd -T output reveals whether GSSAPI is truly off, which a read of /etc/ssh/sshd_config cannot.
describe command('sshd -T') do
its('stdout') { should match(/^gssapiauthentication\s+no$/i) }
endHow to verify it is applied
Run sshd -T | grep -i '^gssapiauthentication'. Expected output is gssapiauthentication no.
Inspect & investigate
Authentication method negotiation is logged in /var/log/auth.log (Debian/Ubuntu) or journalctl -u sshd (RHEL family), more verbosely with LogLevel VERBOSE.
Remediation
Pavois's harden plan writes the sshd_setting directive GSSAPIAuthentication no in a managed drop-in, validates with sshd -t, then reloads the ssh service. Apply it with pavois harden apply.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| directive | gssapiauthentication |
|---|---|
| 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
Before applying, confirm the host does not rely on Kerberos single sign-on over SSH (common in Active Directory / FreeIPA / SSSD-joined environments). If users log in with Kerberos tickets (ssh -K), disabling GSSAPI will force them onto keys or passwords. On standalone hosts there is no impact. The reload preserves active sessions.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 5.1.9, 5.1.11 | 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 |
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.