SSH Hardening: Why Disable PAM When Key-Based Auth Is Already Configured?


2 views

When configuring SSH for key-based authentication, three directives often cause confusion:

PasswordAuthentication no
ChallengeResponseAuthentication no  
UsePAM no

While the first two clearly disable password logins, the purpose of disabling PAM (Pluggable Authentication Modules) is less obvious to many sysadmins.

Even with password authentication disabled, PAM remains active in SSH's authentication flow. This creates potential attack vectors:

  • PAM may still process account expiration checks
  • Environment variables can be modified through PAM modules
  • Some PAM configurations may trigger resource-intensive operations

A real-world example from Ubuntu 20.04's default sshd_config shows PAM processing login even when password auth is disabled:

# grep UsePAM /etc/ssh/sshd_config
UsePAM yes

Benchmarking with sshd in debug mode reveals PAM overhead:

# With PAM enabled:
debug1: PAM: initializing for "root"
debug1: PAM: setting PAM_RHOST to "192.168.1.100"
debug1: PAM: setting PAM_TTY to "ssh"

# With PAM disabled:
debug1: PAM: disabled in configuration

The PAM initialization sequence adds 80-120ms to each connection attempt on average hardware.

For pure key-based authentication systems, the optimal configuration is:

# /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
AuthenticationMethods publickey

Important caveats when disabling PAM:

  • Ensure PermitRootLogin is properly configured
  • Verify account locking mechanisms still function
  • Test session environment variable inheritance

After making changes, validate with:

sshd -t && systemctl reload sshd
ssh -v -o PreferredAuthentications=publickey user@localhost

Check for PAM-related messages in the debug output and verify successful login.

When configuring SSH for key-based authentication, many administrators encounter the UsePAM directive in sshd_config. While it might seem redundant to disable PAM after already disabling password authentication, there are important security implications.

Even with these settings:

PasswordAuthentication no
ChallengeResponseAuthentication no

PAM modules might still execute during the SSH authentication process. This occurs because:

  • PAM handles account validation beyond just passwords
  • Some distributions enable PAM by default for system accounting
  • PAM may enforce other security policies like time restrictions

Disabling PAM provides these benefits when using key-auth only:

UsePAM no
  • Reduced Attack Surface: Eliminates potential PAM-related vulnerabilities
  • Performance: Skips unnecessary PAM stack processing
  • Predictable Behavior: Avoids potential PAM module interference

Here's a complete secure configuration snippet:

# /etc/ssh/sshd_config
Port 22
Protocol 2
PermitRootLogin no
MaxAuthTries 3
LoginGraceTime 60
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Consider maintaining PAM if you need:

  • Kerberos authentication
  • LDAP integration
  • Complex account restrictions
  • Multi-factor authentication

For these cases, you might use:

UsePAM yes
AuthenticationMethods publickey,keyboard-interactive:pam

After changes, always test with:

sshd -t && systemctl restart sshd

And verify PAM isn't being called:

grep pam /var/log/auth.log | grep sshd