How to Fix \"SSH Failed Permission Denied (publickey, gssapi-keyex, gssapi-with-mic)\"?

Secure Shell (SSH) is a network protocol that allows secure communication between two remote computers. It is widely used for system administration, file transfer, and other secure network services. However, one of the most frustrating errors users encounter is the "Permission Denied" error with various authentication methods.

This error typically appears as Permission denied (publickey, gssapi-keyex, gssapi-with-mic) and indicates that the SSH client failed to authenticate using any of the specified methods. Understanding and fixing these authentication failures is crucial for maintaining secure remote access.

Understanding SSH Authentication Methods

SSH supports multiple authentication methods, each serving different security requirements:

Fixing Public Key Authentication Errors

Public key authentication failures are the most common cause of SSH permission denied errors. Follow these steps to resolve them:

Step 1: Check SSH Key Permissions

# Set correct permissions for SSH directory and keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 644 ~/.ssh/authorized_keys

Step 2: Verify Key Locations

# Check if SSH keys exist
ls -la ~/.ssh/

# Test SSH connection with verbose output
ssh -v username@hostname

Step 3: Add Public Key to Server

# Copy public key to remote server
ssh-copy-id username@hostname

# Or manually append the key
cat ~/.ssh/id_rsa.pub | ssh username@hostname "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Fixing GSSAPI Authentication Errors

GSSAPI errors often relate to Kerberos configuration issues. Here's how to troubleshoot them:

Disable GSSAPI Authentication

If GSSAPI is not required, disable it to speed up connections:

# Edit SSH client configuration
vi ~/.ssh/config

# Add these lines
GSSAPIAuthentication no
GSSAPIDelegateCredentials no

Fix Kerberos Issues

# Check Kerberos ticket status
klist

# Obtain new Kerberos ticket
kinit username@DOMAIN.COM

# Verify time synchronization (critical for Kerberos)
ntpdate -s time.server.com

Advanced Troubleshooting

Using SSH Agent

SSH Agent manages your private keys and passphrases securely:

# Start SSH agent
eval "$(ssh-agent -s)"

# Add private key to agent
ssh-add ~/.ssh/id_rsa

# List loaded keys
ssh-add -l

Generate New SSH Key Pair

If existing keys are corrupted or incompatible:

# Generate new RSA key pair
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

# Generate ED25519 key (more secure)
ssh-keygen -t ed25519 -C "your_email@example.com"

Server-Side Configuration

Sometimes the issue lies in the SSH server configuration. Check these settings in /etc/ssh/sshd_config:

# Enable public key authentication
PubkeyAuthentication yes

# Set authorized keys file location
AuthorizedKeysFile .ssh/authorized_keys

# Disable password authentication (optional)
PasswordAuthentication no

# Restart SSH service after changes
systemctl restart sshd

Common sshd_config Security Settings

Debugging SSH Connections

Use verbose mode to identify the exact cause of authentication failures:

# Maximum verbosity for detailed debugging
ssh -vvv username@hostname

# Check server logs for authentication attempts
tail -f /var/log/auth.log

Quick Fix Commands

For immediate troubleshooting, try these commands in sequence:

# Fix permissions
chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_rsa && chmod 644 ~/.ssh/id_rsa.pub

# Disable GSSAPI temporarily
ssh -o GSSAPIAuthentication=no username@hostname

# Force password authentication
ssh -o PreferredAuthentications=password username@hostname

# Use specific key file
ssh -i ~/.ssh/id_rsa username@hostname

Conclusion

SSH permission denied errors are typically caused by incorrect key permissions, missing public keys, or misconfigured authentication methods. Most issues can be resolved by fixing file permissions, properly configuring SSH keys, or disabling unused authentication methods like GSSAPI. Regular maintenance of SSH configurations and keys ensures reliable and secure remote access.