Fix SSH Failed Permission Denied (publickey, gssapi-keyex, gssapi-with-mic)

When you're experiencing an SSH connectivity error, there are several ways to troubleshoot the problem, depending on what's causing it.

One of the most useful techniques is to enable SSH verbose mode, which provides detailed diagnostic information about the connection process, configuration, and authentication.

In this tutorial, we'll explore how to troubleshoot SSH authentication failures, understand the Permission denied error, and correct file permissions that may prevent you from accessing your Linux server.

Let's get started.

1. Enable SSH Debugging Mode

SSH provides three levels of verbosity to help you diagnose connection problems.

• Level 1: -v — Displays basic debugging information.
• Level 2: -vv — Provides more detailed debugging information.
• Level 3: -vvv — Displays extensive debugging information, useful for diagnosing complex SSH connection and authentication issues.

To enable verbose mode, run the following command from your client machine, replacing server_ip with your server's IP address.

Level 1:

$ ssh -v user@server_ip

Level 2:

$ ssh -vv user@server_ip

Level 3:

$ ssh -vvv user@server_ip

Replace user with your remote username.

For example, if you're connecting to a server using a nonstandard SSH port, you can specify the port with the -p option:

$ ssh -vvv -p 2222 user@server_ip

Verbose output can reveal useful details, including:

• Whether the client can reach the SSH server.
• Which SSH configuration files are being read.
• Which identity files the client attempts to use.
• Whether public-key authentication succeeds.
• Which authentication methods the server offers.
• Where the connection or authentication process fails.

Tip: Start with -v and increase the verbosity when necessary. The -vvv option is particularly useful when investigating public-key authentication failures.

2. Understand the SSH Permission Denied Error

Suppose you attempt to connect to a Linux server and receive the following message:

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

What does this mean?

The message indicates that the server did not accept the authentication attempt and lists the authentication methods advertised in the failure response.

In this example, the methods are:

• publickey: Public-key authentication.
• gssapi-keyex: GSSAPI key exchange authentication.
• gssapi-with-mic: GSSAPI authentication using a message integrity code.

The error does not necessarily mean your public key is incorrect.

Several issues can cause SSH authentication to fail, including:

• The wrong username.
• A missing or incorrect public key in the remote user's authorized_keys file.
• The client offering the wrong private key.
• Incorrect ownership or permissions on the user's home directory or .ssh files.
• SSH server configuration restrictions.
• Account restrictions or authentication policies.

The verbose output can help narrow down the cause.

For example, you might see:

debug1: Offering public key: /home/user/.ssh/id_ed25519
debug1: Authentications that can continue: publickey
Permission denied (publickey).

This indicates that the client offered a public key but authentication did not succeed with the available methods.

Continue investigating the client identity, the remote user's authorized keys, and the SSH server's configuration and logs.

Important: SSH authentication failures are not always caused by incorrect file permissions. Verify the actual cause before changing permissions or modifying the server configuration.

3. Understanding SSH StrictModes

One SSH server setting worth checking is StrictModes.

The StrictModes option instructs the SSH daemon (sshd) to check the ownership and permissions of certain user files and directories before accepting a login.

These checks help protect against situations in which unauthorized users could modify authentication-related files.

When StrictModes is enabled, SSH may reject public-key authentication if the relevant ownership or permission checks fail.

On most OpenSSH installations, StrictModes is enabled by default.

The setting is commonly defined in:

/etc/ssh/sshd_config

To inspect it, run the following command on the server:

$ sudo grep -nE '^[[:space:]]*StrictModes' /etc/ssh/sshd_config

You might find:

#StrictModes yes

The leading # means this line is commented out. In this case, the default setting applies, which is normally yes.

You can also inspect the effective configuration with:

$ sudo sshd -T | grep -i strictmodes

Expected output:

strictmodes yes

The effective configuration is more informative than inspecting the configuration file alone because OpenSSH may also read settings from included configuration files.

Recommendation: Keep StrictModes enabled unless you have a specific, well-understood reason to change it. Disabling this protection is not the appropriate fix for incorrectly secured SSH files.

4. Correct SSH File Permissions

If your investigation identifies incorrect ownership or permissions, correct the affected files and directories.

For public-key authentication, the remote user's home directory, .ssh directory, and authorized_keys file must have appropriate ownership and permissions.

A common configuration is:

• Home directory: Not writable by group or other users.
• .ssh directory: 700 (drwx------).
• authorized_keys: 600 (-rw-------).
• Private key on the client: 600 (-rw-------).
• Public key on the client: 644 (-rw-r--r--).

These are common secure defaults, not universal requirements for every file. The server-side authorized_keys file and the client's private key serve different purposes.

Step 1: Check the Remote User's Home Directory

On the server, inspect the home directory of the affected user.

For example:

$ ls -ld /home/user

Replace /home/user with the actual home directory.

If the account is named user, you can check its account information with:

$ getent passwd user

This displays the account entry, including its configured home directory.

The home directory should generally not be writable by group or other users when StrictModes is enabled.

Do not run chmod against /home itself to fix an individual user's permissions. The /home directory is a parent directory that may contain multiple users' home directories, and its permissions should be managed separately.

Step 2: Check the .ssh Directory

Inspect the directory:

$ ls -ld /home/user/.ssh

A common secure permission setting is:

drwx------ 

To correct the permissions, run:

$ sudo chmod 700 /home/user/.ssh

Make sure the directory belongs to the intended user.

For example:

$ sudo chown user:user /home/user/.ssh

Replace user:user with the appropriate username and group on your system.

Step 3: Check the authorized_keys File

The authorized_keys file contains the public keys permitted to authenticate as that remote user.

Inspect its permissions:

$ ls -l /home/user/.ssh/authorized_keys

A common secure permission setting is:

-rw-------

To correct the permissions:

$ sudo chmod 600 /home/user/.ssh/authorized_keys

Correct the ownership if necessary:

$ sudo chown user:user /home/user/.ssh/authorized_keys

Remember: The remote server needs the client's public key in the correct user's authorized_keys file. Changing permissions alone will not fix a missing or incorrect public key.

Step 4: Check the Client's SSH Keys

On the client machine, inspect your SSH key files.

For example:

$ ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

If you use an RSA key, the filenames may instead be id_rsa and id_rsa.pub.

Your private key should not be accessible to other users.

To correct its permissions:

$ chmod 600 ~/.ssh/id_ed25519

The public key can normally have permissions of 644:

$ chmod 644 ~/.ssh/id_ed25519.pub

These commands apply to the client's own key files. Do not confuse the client's private key with the remote server's authorized_keys file.

If your key is stored under a different filename, substitute the correct path.

Step 5: Test the Connection Again

Once you've corrected any identified problems, retry the connection with verbose output:

$ ssh -vvv user@server_ip

If authentication still fails, inspect the SSH server logs. Depending on the Linux distribution, useful commands include:

$ sudo journalctl -u ssh -n 50 --no-pager

On systems where the service is named sshd, use:

$ sudo journalctl -u sshd -n 50 --no-pager

On Debian or Ubuntu, authentication messages may also be recorded in:

$ sudo tail -n 50 /var/log/auth.log

Check which logging service and file your distribution uses.

Server logs can help distinguish permission problems from rejected keys, invalid usernames, and other authentication failures.

5. Troubleshooting SSH Authentication With Google Authenticator (TOTP)

If your SSH server uses Google Authenticator for time-based one-time password (TOTP) authentication, you may also need to investigate the user's authenticator configuration.

The google-authenticator PAM integration commonly stores its configuration in a file named:

~/.google_authenticator

The exact location and permission requirements depend on how the PAM module and SSH authentication are configured.

A common secure permission setting for this file is 400 (-r--------), allowing the owner to read it without granting access to other users.

To inspect the file's permissions, run the following command as the affected user:

$ ls -l ~/.google_authenticator

If the file exists and its permissions need correcting, run:

$ chmod 400 ~/.google_authenticator

If necessary, verify its ownership as well:

$ ls -l ~/.google_authenticator

Important: The 400 permission setting is a common recommendation, not a universal requirement for every TOTP implementation. Confirm the requirements of your installed PAM module and SSH configuration before changing permissions.

If TOTP authentication fails, also check:

• Whether the user's authenticator configuration file exists.
• Whether the PAM configuration is correct.
• Whether SSH is configured to use the intended authentication methods.
• Whether the server and authenticator device have sufficiently synchronized clocks.
• Whether the server logs identify a PAM or verification failure.

Remember that TOTP authentication problems and public-key authentication problems are distinct, even though either can prevent an SSH login.

SSH debugging is an essential skill for Linux system administrators, especially when managing remote servers.

By enabling verbose output with ssh -v, ssh -vv, or ssh -vvv, you can investigate connection problems and narrow down authentication failures.

Understanding StrictModes, verifying file ownership and permissions, checking authorized keys, and inspecting server logs will help you troubleshoot many common SSH access problems.

If you're using Google Authenticator or another TOTP integration, remember to investigate the PAM configuration and authenticator-related logs as well.

The key is to diagnose the actual cause before changing permissions or weakening security controls.

We hope this tutorial helps you troubleshoot your next SSH authentication issue.

Happy Linux administration.