While trying to ssh a host you might encounter an error – Permission Denied (publickey, gssapi-keyex, gssapi-with-mic). This says that you are not allowed to access the host via ssh.
But why you got this error?
Maybe because your public key is wrong. Or maybe there is another issue in the server and it is returning the wrong message.
What is Permission Denied (publickey, gssapi-keyex, gssapi-with-mic)?
Before solving any error, we should know the root causes. Permission denied means you can’t access the server. This could be due to wrong key or ssh server could not access the public keys file, authorized_keys
.
Let’s understand the error first. It indicates these 3 things – publickey
, gssapi-keyex
and gssapi-with-mic
.
gssapi
stands for Generic Security Services Application Program Interface. According to Oracle docs – “gssapi provides a way for applications to protect data that is sent to peer applications; typically, this might be from a client on one machine to a server on another“.
gssapi is used by Kerberos. If you are not using Kerberos and only authenticating with password or ssh public key then you don’t need gssapi. Hence you can disable them. We will discuss about disabling gssapi in the next section.
Solution
To solve this issue you need to disable gssapi authentication as well as set appropriate permissions to the .ssh
directory and .ssh/authorized_keys
file.
First of all let’s set the permissions.
Step1: Permission for home and .ssh needs to be 0700 or drwx——
Owner permission for home and .ssh directory needs to be read, write, execute. That is, 0700 or drwx——. Follow these steps –
1. Move to your user folder in home directory using this command –
cd ~
2. Check directory permission using ls -ld
command –
ls -ld
After running this command you will get output like this –
drwxr-xr-x 4 akamit akamit 4096 Sep 17 02:16
The owner permission needs to be read, write and execute (rwx). Group and others permission could be none for maximum security. In my case they are set to read and execute (r-x).
What are owner permissions? The first 3 characters after d
represents owner permissions, next 3 group permissions and last 3 others permissions. Shown in the below code block –
# Owner Others # | | d rwx r-x r-x # | # Group
If your owner permission is different than this then set it using chmod command. You will need the absolute path to your user directory. If you don’t know that then use ~ to enter into your user directory and then run pwd
for getting path –
chmod 0700 ~ # OR cd ~ pwd chmod 0700 /home/{YOUR_USERNAME}
3. Check permission for ~/.ssh
directory
First move into .ssh
directory using the below command –
cd ~/.ssh
Next, check the permission using ls -ld
command –
ls -ld
The output should be read, write and execute permission for owner on this directory. For me the output looks like this –
You can see from the terminal image that the permission assigned to my .ssh
directory is drwx------
.
If it is not the same for you, then change the permission using chmod command –
chmod 0700 ~/.ssh
Step 2: Permission of authorized_keys file needs to be 0600
authorized_keys
is the file inside .ssh
directory which holds the list of all the public keys that are allowed to login using ssh. So, in order to allow an ssh request, the server needs to open this file and match the provided key with the keys in this file. If there is a match then authentication is successful. Otherwise permission denied.
What if public key is correct but server is not able to access authorized_keys
file? In that case server will return permission denied. Although you have passed the correct key. That’s why it is required to have a proper permission on this file for owner account.
Check the permission using the below command –
ls -ld ~/.ssh/authorized_keys
It should return the permission as -rw-------
. That is, the owner can read and write but not accessible to anybody else. For me the output looks like this –
[email protected]:~$ ls -la ~/.ssh/authorized_keys -rw------- 1 akamit akamit 553 Apr 17 10:33 /home/akamit/.ssh/authorized_keys [email protected]:~$
If the permission of this file is not the same as shown above then use chmod to change it –
chmod 0600 ~/.ssh/authorized_keys
Step 3: Prevent insecure password authentication
Password authentication should not be used for better security. We need to use public_key based ssh authentication. In this step we will turn off password authentication and enable public key authentication.
Open /etc/ssh/sshd_config
file –
sudo vim /etc/ssh/sshd_config
This file will look like this –
# $OpenBSD: sshd_config,v 1.103 2022/04/09 20:41:22 tj Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. Include /etc/ssh/sshd_config.d/*.conf #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin prohibit-password #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 #PubkeyAuthentication yes # Expect .ssh/authorized_keys2 to be disregarded by default in future. #AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no #PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes #GSSAPIStrictAcceptorCheck yes #GSSAPIKeyExchange no # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes #AllowAgentForwarding yes #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes #X11DisplayOffset 10 #X11UseLocalhost yes #PermitTTY yes PrintMotd no #PrintLastLog yes #TCPKeepAlive yes #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS no #PidFile /var/run/sshd.pid #MaxStartups 10:30:100 #PermitTunnel no #ChrootDirectory none #VersionAddendum none # no default banner path #Banner none # Allow client to pass locale environment variables AcceptEnv LANG LC_* # override default of no subsystems Subsystem sftp /usr/lib/openssh/sftp-server # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # PermitTTY no # ForceCommand cvs server
We are interested in highlighted lines only. The values of these properties should be –
- PermitRootLogin – no
- PubkeyAuthentication – yes
- GSSAPIAuthentication – no (Or keep it commented out)
- GSSAPICleanupCredentials – yes (Or keep it commented out)
- UsePAM – yes
Step 4 – Restart SSH service
After making these changes, you need to restart SSH service. Use this command –
systemctl restart sshd
Conclusion
SSH throws permission denied error when either the public key is invalid or there is some problem with sshd configuration. It could be missing permissions on .ssh directory or authorized_keys file. In this article we saw the solution to all these issues. Follow the steps and you will be able to successfully log into the system through ssh.