Troubleshooting Excessive SSH Login Delay in CentOS 7: GSSAPI and Authentication Timeout Issues


29 views

When experiencing extended SSH login delays on CentOS 7, particularly after the SSH2_MSG_SERVICE_ACCEPT message, we're typically looking at authentication mechanism negotiation issues. The verbose output shows the system attempting multiple authentication methods before falling back to password authentication.

# Typical verbose output showing the delay pattern
debug1: SSH2_MSG_SERVICE_ACCEPT received
[...long pause...]
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

The primary suspects for this behavior are:

  • GSSAPI authentication attempting to contact unavailable Kerberos servers
  • DNS resolution timeouts during the authentication process
  • SSH client/server configuration mismatches

First, check your current SSH daemon configuration:

# View current SSHD configuration
sudo cat /etc/ssh/sshd_config | grep -i gssapi
sudo cat /etc/ssh/sshd_config | grep -i dns

Modify your SSH client configuration (~/.ssh/config or /etc/ssh/ssh_config):

Host *
    GSSAPIAuthentication no
    GSSAPIDelegateCredentials no
    GSSAPIKeyExchange no
    UseDNS no

For the server-side configuration (/etc/ssh/sshd_config), add:

# Disable GSSAPI and DNS lookups
GSSAPIAuthentication no
UseDNS no

After making changes, restart the SSH daemon and test:

sudo systemctl restart sshd
time ssh -v localhost

For more detailed diagnostics, try:

# Full debug output
ssh -vvv user@host

# Network-level debugging
sudo tcpdump -i any port 22 -w ssh_debug.pcap

To prevent future occurrences across all users:

# Create system-wide SSH client config
sudo tee /etc/ssh/ssh_config.d/99-disable-gssapi.conf <

When debugging SSH connection delays on CentOS 7, the verbose output reveals a critical pattern:

debug1: SSH2_MSG_SERVICE_ACCEPT received
[1-2 minute delay occurs here]
debug1: Authentications that can continue: publickey,password

The core issue stems from GSSAPI authentication attempts timing out. Here's what happens during the handshake:

  • SSH client initiates GSSAPI authentication by default
  • System waits for Kerberos ticket verification
  • After timeout falls back to password auth

Modify SSH client configuration to disable GSSAPI completely:

sudo vi /etc/ssh/sshd_config

# Add these lines at the end:
GSSAPIAuthentication no
UseDNS no

Then restart the SSH service:

systemctl restart sshd

For temporary testing, force disable GSSAPI during connection:

ssh -o GSSAPIAuthentication=no -o GSSAPIKeyExchange=no user@host

The UseDNS setting can compound delays. Verify with:

time host $(hostname)
time dig $(hostname)

If these take >1s, disable reverse DNS checks:

echo "UseDNS no" >> /etc/ssh/sshd_config
  1. Run SSH with maximum verbosity: ssh -vvv user@host
  2. Check system logs: journalctl -u sshd -f
  3. Test network latency: tcping ssh_port host
  4. Verify PAM modules: grep pam_ /etc/ssh/sshd_config

If using Kerberos, ensure proper configuration:

kinit -kt /etc/krb5.keytab host/$(hostname -f)@REALM
klist -e

Check krb5.conf for correct realm settings.