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

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

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):

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

Then fix permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

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

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

Or manually:

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:

ssh user@remote-host "chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

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

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

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

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:

GSSAPIAuthentication no

Validate the config, then restart SSH:

sudo sshd -t
sudo systemctl restart sshd
# or on older systems:
sudo service ssh restart

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

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:

sudo journalctl -u sshd -f

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

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:

# 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:

restorecon -R -v ~/.ssh

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

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:

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