Permission denied (publickey) SSH Error on Linux

SSH is a powerful tool for connecting to remote machines, but you might encounter a frustrating roadblock in the form of the “Permission denied (publickey)” error when dealing with public SSH keys on Linux. This error can be baffling, but fear not—there are effective solutions to troubleshoot it and regain seamless access to your remote servers.

What Is a Public Key?

When you generate a key pair for SSH on Linux, you receive both a public key and a private key. The private key is your closely guarded secret, while the public key is shared with remote servers, allowing you to log in without a password. Your local SSH client matches the public key to the private key during the connection process.

The advantage here is clear: you only need to share the public key. As long as your private key remains secure, your system should stay protected even if your public key is compromised. On its own, the public key is useless to malicious actors.

OpenSSH, the most widely-used SSH client and server in the open-source world, requires specific permissions for the file containing public keys on the remote machine (usually “.ssh/authorized_keys” in your home directory). It must not have write permissions set for other users, also known as being “world-writable.” Since the directory name begins with a period (.), it won’t appear in standard ‘ls’ listings unless you use ‘ls -A’ to reveal hidden files.

These permissions may change if the file was copied from another computer or created manually. Thankfully, this issue can be easily resolved.

Check Your Public Key Permissions

The ‘authorized_keys’ file is a plain-text file containing public keys from clients you want to grant access to your remote account. To check its permissions, use the ‘ls’ command with the ‘-l’ option:




This command reveals permission settings for the owner, group, and others. Pay special attention to the last six characters in the string. If you see a “w” among them, it indicates that the group or others can write to it, rendering it insecure.

Your goal is to make this file writable by you but not by the group or others. To grant the correct permissions, you can use either the numeric or symbolic method.

The numeric approach is shorter but requires you to memorize octal permission numbers:




Safely Copy Keys Using ssh-agent

While you can manually copy and paste public keys into the ‘~/.ssh/.authorized_keys’ file, employing the ‘ssh-agent’ program reduces the chances of permissions errors. To start ‘ssh-agent,’ use the following command:




Check the Remote Server’s sshd Settings

If the previous solutions fail, it might be necessary to make configuration adjustments to the ‘sshd’ server on the remote machine. If you have root access, you can do this; otherwise, contact the system administrator for assistance. Note that this is a last resort, as it could potentially compromise system security.

The system-wide configuration file for ‘sshd’ is typically located at ‘/etc/ssh/sshd_config,’ and it’s owned by root. Therefore, you’ll need to use ‘sudo’ to edit it. For instance, you can edit it with Vim:

To enable ‘sshd’ to allow logins even if your ‘authorized_keys’ file is world-writable, set the ‘StrictModes’ option to ‘no’ in this file. After making this change, save it and restart the SSH server:

Conclusion

Encountering SSH public key permission errors on remote systems is a common challenge. Fortunately, in most cases, resolving these issues is straightforward: ensure your key file’s permissions prevent unauthorized access, consider using ‘ssh-agent’ for more reliable connections, and, as a last resort, adjust the SSH server’s settings if you have the necessary access. With these solutions at your disposal, you can conquer the “Permission denied (publickey)” SSH error and regain control of your remote connections.

Table: Troubleshooting SSH “Permission denied (publickey)” Error