SSH Permission Denied (Publickey) – Forcing Password Authentication When Key-Based Login Fails


33 views

Many developers encounter this frustrating scenario: you're trying to SSH into a server with password authentication, but instead of being prompted for credentials, you immediately receive a "Permission denied (publickey,gssapi-with-mic)" error. This happens because SSH defaults to key-based authentication when available.

First, check your server's SSH configuration file (typically at /etc/ssh/sshd_config). You'll need root access or sudo privileges to modify this file.

# Edit the SSH configuration
sudo nano /etc/ssh/sshd_config

# Ensure these settings are present:
PasswordAuthentication yes
PubkeyAuthentication no  # Temporarily disable for testing
ChallengeResponseAuthentication yes
UsePAM yes

After making changes, restart the SSH service:

sudo systemctl restart sshd
# Or for older systems:
sudo service ssh restart

When connecting from your client machine, you can explicitly disable key authentication:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no username@hostname

Alternatively, temporarily move your private keys:

mkdir ~/ssh_backup
mv ~/.ssh/id_* ~/ssh_backup/

If you're still encountering problems:

  • Verify the user account exists on the server: getent passwd username
  • Check SELinux status: sestatus
  • Inspect auth logs: sudo tail -f /var/log/auth.log (or /var/log/secure on RHEL)

While password authentication may be necessary for troubleshooting, it's significantly less secure than key-based authentication. Consider these best practices:

# After resolving the issue, re-enable key auth with:
PubkeyAuthentication yes
PasswordAuthentication no

For temporary access, consider using ssh-copy-id to set up key authentication properly:

ssh-copy-id username@hostname

When SSH immediately denies access with "Permission denied (publickey,gssapi-with-mic)" without prompting for a password, this indicates the server is configured to prioritize public key authentication over password authentication. This happens because:

# Common default SSHd configuration causing this behavior:
PubkeyAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey

First, modify the SSH daemon configuration (requires root access):

sudo nano /etc/ssh/sshd_config

Make these critical changes:

# Enable password authentication
PasswordAuthentication yes

# Optional: Specify authentication method order
AuthenticationMethods publickey,password

Then restart the SSH service:

sudo systemctl restart sshd

If you can't modify server configuration, force password authentication from the client:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@hostname

For persistent configurations, add to ~/.ssh/config:

Host problematic-host
    HostName host.example.com
    User yourusername
    PreferredAuthentications password
    PubkeyAuthentication no

If changes don't take effect:

  1. Verify SELinux isn't blocking modifications: sudo setenforce 0 (temporarily)
  2. Check for conflicting Match blocks in sshd_config
  3. Ensure PAM is properly configured: sudo pam-auth-update

When enabling password authentication:

# Always set these security measures:
PermitEmptyPasswords no
MaxAuthTries 3
LoginGraceTime 30
UsePAM yes