How to fix Permission denied (publickey,gssapi-keyex,gssapi-with-mic). in SSH

SSHINTERMEDIATEMEDIUMUpdated May 28, 2026· 584 views

SSH rejects all offered authentication methods (publickey, gssapi-keyex, gssapi-with-mic). Usually a public key, permissions, or Kerberos/GSSAPI misconfiguration on the client or server.

Quick fix

Fixes Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

ls -la ~/.ssh/id_ed25519 ~/.ssh/id_rsa 2>/dev/null
  1. Verify SSH key exists and is readable
  2. Copy public key to remote server
  3. Verify server SSH configuration
  4. Debug with verbose SSH output
ssh — error
ls -la ~/.ssh/id_ed25519 ~/.ssh/id_rsa 2>/dev/null
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

What this error means

This error indicates that the SSH server rejected the client's attempt to authenticate using any of the available methods: public key authentication, GSSAPI key exchange, or GSSAPI with mutual authentication (gssapi-with-mic). The message lists the authentication methods the server is willing to accept, but the client either doesn't have correct credentials or those credentials are not properly configured. This is common in enterprise environments using Kerberos/GSSAPI for single sign-on, as well as in standard public key authentication setups. The error is not specific about which method failed - it simply means every method the client attempted was rejected.

Typical symptoms

  • SSH connection immediately disconnects with a 'Permission denied' message
  • Cannot log in even when you believe you have the correct key
  • SSH client offers authentication methods but the server rejects all of them
  • Verbose SSH output (ssh -vvv) shows GSSAPI exchange or public key attempted but failing
  • Works from some machines but not others (especially when GSSAPI is involved)

Common causes

  1. SSH public key not present in the server's ~/.ssh/authorized_keys file
  2. Incorrect permissions on ~/.ssh or the key files (commonly too permissive)
  3. SSH key pair mismatch - the private key on the client does not match the public key on the server
  4. Server-side sshd_config has PubkeyAuthentication disabled or GSSAPIAuthentication misconfigured
  5. Home directory is group- or world-writable, so sshd refuses to trust ~/.ssh
  6. GSSAPI/Kerberos misconfiguration - missing or invalid keytab on the server, or an expired Kerberos ticket on the client
  7. Hostname or realm mismatch in the Kerberos/GSSAPI setup
  8. SSH daemon not restarted after configuration changes

How to fix "Permission denied (publickey,gssapi-keyex,gssapi-with-mic)."

1Verify SSH key exists and is readable

Check that your private key exists and has correct permissions on the client machine:

bash
ls -la ~/.ssh/id_ed25519 ~/.ssh/id_rsa 2>/dev/null

If you have no key, generate one (Ed25519 is preferred; use 4096-bit RSA only when Ed25519 is unsupported):

bash
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

Then fix permissions:

bash
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
2Copy public key to remote server

Add your public key to the server's authorized_keys file. The easiest way is ssh-copy-id:

bash
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-host

Or manually:

bash
cat ~/.ssh/id_ed25519.pub | ssh user@remote-host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Then ensure the file and directory have the permissions sshd requires:

bash
ssh user@remote-host "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"
3Verify server SSH configuration

Log in to the server (you may need password authentication temporarily) and check the effective sshd settings:

bash
sudo sshd -T | grep -Ei 'pubkeyauthentication|authorizedkeysfile|gssapiauthentication'

Make sure public key authentication is enabled in /etc/ssh/sshd_config:

bash
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

If you are not actually using Kerberos/GSSAPI, disabling it removes a moving part while troubleshooting:

bash
GSSAPIAuthentication no

Validate the config, then restart SSH:

bash
sudo sshd -t
sudo systemctl restart sshd
# or on older systems:
sudo service ssh restart
4Debug with verbose SSH output

Run SSH with maximum verbosity to see exactly where authentication fails:

bash
ssh -vvv user@remote-host

The output shows:
- Which key the client offers ("Offering public key")
- Whether the server accepts or rejects it
- Which authentication method is attempted
- Specific GSSAPI or key-exchange error messages

Useful indicators:
- Offering public key then Authentications that can continue - the server rejected that key (not in authorized_keys, or a permissions problem)
- gssapi-with-mic: Unspecified GSS failure - a Kerberos/GSSAPI problem (see advanced notes)

Server-side, watch the logs at the same time:

bash
sudo journalctl -u sshd -f

Messages like "Authentication refused: bad ownership or modes for directory" point directly at the next step.

5Fix home and ~/.ssh ownership and permissions

For public key authentication, sshd refuses to trust ~/.ssh (in StrictModes, the default) when the home directory or ~/.ssh is writable by group or other, or is not owned by the user. Note that this is about *write* access, not read access - the safest fix is simply to remove group/other write bits:

bash
# On the server, as the target user
chmod go-w ~          # remove group/other write from the home directory
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R "$USER:$USER" ~/.ssh

chmod go-w ~ keeps whatever read/execute access your environment already relies on while satisfying sshd's StrictModes check. If you want the home directory itself to be private, use chmod 700 ~ instead (do not use 755, which leaves it readable by other users).

On RHEL/CentOS/Fedora with SELinux, also restore the correct security context:

bash
restorecon -R -v ~/.ssh
6Test public key authentication without GSSAPI

If it still fails and GSSAPI is involved, disable GSSAPI on the client to isolate the problem:

bash
ssh -o GSSAPIAuthentication=no user@remote-host

If this works, the problem is in your GSSAPI/Kerberos setup. If it still fails, focus on public key authentication.

To make the GSSAPI change permanent for that host:

bash
# ~/.ssh/config
Host remote-host
    HostName remote-host
    User user
    IdentityFile ~/.ssh/id_ed25519
    GSSAPIAuthentication no

Advanced notes

GSSAPI/Kerberos-specific issues

If you use GSSAPI (common with Active Directory or Kerberos SSO), the server needs:
1. A valid Kerberos host principal (check with sudo klist -k on the server)
2. A correct /etc/krb5.conf
3. A valid Kerberos ticket on the client (check with klist; renew with kinit)

Common GSSAPI errors and their meaning:
- "Wrong principal in request" - hostname mismatch between how you connect and the Kerberos principal/realm
- "Key table entry not found" - missing or stale /etc/krb5.keytab on the server
- "Unspecified GSS failure" - expired ticket or configuration mismatch

On RHEL 8+ with SSSD + Active Directory, make sure /etc/krb5.conf includes the SSSD-managed configuration so the right realm and keytab are used.

OpenSSH version differences

Older OpenSSH releases differ in default key-type and algorithm support. Recent versions disable the legacy ssh-rsa (SHA-1) signature algorithm by default, which can cause an otherwise-valid RSA key to be rejected - prefer Ed25519 keys, and check ssh -V on both ends if behavior differs between machines.

Windows clients (PuTTY/WinSCP)

PuTTY-family tools use the .ppk private key format. Convert to OpenSSH format with PuTTYgen (Conversions -> Export OpenSSH key) if you need to use the same key with the ssh command line.

Frequently asked questions

What does "Permission denied (publickey,gssapi-keyex,gssapi-with-mic)." mean?
This error indicates that the SSH server rejected the client's attempt to authenticate using any of the available methods: public key authentication, GSSAPI key exchange, or GSSAPI with mutual authentication (gssapi-with-mic). The message lists the authentication methods the server is willing to accept, but the client either doesn't have correct credentials or those credentials are not properly configured. This is common in enterprise environments using Kerberos/GSSAPI for single sign-on, as well as in standard public key authentication setups.
How do I fix "Permission denied (publickey,gssapi-keyex,gssapi-with-mic)."?
SSH rejects all offered authentication methods (publickey, gssapi-keyex, gssapi-with-mic). Usually a public key, permissions, or Kerberos/GSSAPI misconfiguration on the client or server.
What causes "Permission denied (publickey,gssapi-keyex,gssapi-with-mic)."?
SSH public key not present in the server's ~/.ssh/authorized_keys file Incorrect permissions on ~/.ssh or the key files (commonly too permissive) SSH key pair mismatch - the private key on the client does not match the public key on the server
Is the "Permission denied (publickey,gssapi-keyex,gssapi-with-mic)." error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading