SSH Permission Denied: Causes and Quick Fixes for Linux

What Does the "Permission denied" Error Mean

The SSH Permission denied error appears when the SSH daemon (sshd) on the target server refuses authentication. The message may look like this:

Permission denied (publickey,password).

Or, if a specific method is used:

Permission denied (publickey).

The error occurs at the authentication stage, meaning the connection is established, but the server does not allow the user in. This is not a network failure (unlike Connection refused), but a problem with credentials or security settings.

Causes

1. Incorrect credentials — wrong username, password, or using the wrong private key.
2. Incorrect permissions on ~/.ssh files — on the server, the .ssh folder or authorized_keys file must have strict permissions (700 and 600 respectively) and belong to the target user.
3. Disabled authentication methods in sshd_config — for example, PasswordAuthentication no when attempting to log in with a password.
4. User is locked or has no shell — in /etc/passwd, the user has /usr/sbin/nologin or /bin/false.
5. SELinux/AppArmor — security context prevents access to ~/.ssh.
6. IP blocking — via fail2ban, denyhosts, or hosts.deny.
7. Key mismatch — the public key on the server does not match the private key on the client.
8. Restrictions in sshd_config — AllowUsers, DenyUsers, AllowGroups, DenyGroups exclude the user.
9. Host key issues — although this usually causes a different warning, it can sometimes affect authentication.

Method 1: Checking Credentials and Basic Steps

Ensure you are attempting to log in with the correct username and authentication method.

1. Specify the user explicitly in the command:

   ssh -l username server_ip
   

   
   or

   ssh username@server_ip
   

2. When using a key, check that the private key is loaded into ssh-agent:

   ssh-add -l
   

   
   If the list is empty, add the key:

   ssh-add ~/.ssh/id_rsa
   

   
   Or specify the key directly:

   ssh -i ~/.ssh/id_rsa username@server_ip
   

3. When using a password, ensure the password is correct and the account has no restrictions (e.g., password expiration).
4. Check if the server is reachable (network layer):

   ping server_ip
   nc -zv server_ip 22
   

💡 Tip: If you are unsure which authentication method is being used, try explicitly specifying -o PubkeyAuthentication=no for password or -o PreferredAuthentications=publickey for key.

Method 2: Fixing Permissions on .ssh Files on the Server

Incorrect permissions are the most common cause. Connect to the server via console (if you have physical access) or use an alternative method (e.g., your cloud provider's web console).

1. Log in to the server under the account you are trying to connect to via SSH (or as root).
2. Check current permissions:

   ls -la ~/.ssh
   

   
   Expected output:

   drwx------ 2 user user 4096 Feb 16 12:00 .
   drwxr-xr-x 5 user user 4096 Feb 16 12:00 ..
   -rw------- 1 user user  400 Feb 16 12:00 authorized_keys
   

3. Fix permissions:

   chmod 700 ~/.ssh
   chmod 600 ~/.ssh/authorized_keys
   chown -R $(whoami):$(whoami) ~/.ssh
   

4. For SELinux (if used):

   restorecon -Rv ~/.ssh
   

5. Restart the SSH daemon:

   sudo systemctl restart sshd
   

Method 3: Checking and Configuring sshd_config

The sshd_config configuration file can block authentication.

1. Open the file:

   sudo nano /etc/ssh/sshd_config
   

   
   or

   sudo vi /etc/ssh/sshd_config
   

2. Ensure lines have correct values:

   PubkeyAuthentication yes
   PasswordAuthentication yes   # if using a password
   PermitRootLogin no           # or prohibit-password, but not yes for security
   ChallengeResponseAuthentication no
   UsePAM yes
   

3. Check access directives:
   • If AllowUsers or AllowGroups exists, ensure your user is listed.
   • If DenyUsers or DenyGroups exists, ensure your user is not in the list.
4. Reload the configuration:

   sudo systemctl restart sshd
   

   
   Or check syntax before reloading:

   sudo sshd -t
   

5. If you changed the port (via Port), ensure you are connecting to the correct port:

   ssh -p 2222 username@server_ip
   

Method 4: Analyzing SSH Logs

Logs contain the exact reason for the denial.

1. On the server, view logs in real-time while attempting a connection:
   • Ubuntu/Debian:

     sudo tail -f /var/log/auth.log
     

   • RHEL/CentOS/Fedora:

     sudo tail -f /var/log/secure
     

2. Typical entries:
   • Failed publickey for username from client_ip port ...: key problem.
   • Failed password for username from client_ip port ...: incorrect password or password authentication disabled.
   • User username not allowed because not listed in AllowUsers: restriction in config.
   • User username not allowed because shell /usr/sbin/nologin not listed in /etc/shells: shell forbidden.
3. Use grep to filter:

   sudo grep "sshd.*Failed" /var/log/auth.log
   

Method 5: Checking Blocks and SELinux/AppArmor

Checking IP Blocks

1. Check fail2ban (if installed):

   sudo fail2ban-client status sshd
   

   
   If your IP is in the list, unban it:

   sudo fail2ban-client set sshd unbanip client_ip
   

2. Check hosts.deny:

   cat /etc/hosts.deny
   

   
   If there is a line sshd: ALL or sshd: client_ip, remove it or add an exception in hosts.allow.
3. Check iptables/nftables:

   sudo iptables -L -n | grep 22
   sudo nft list ruleset | grep 22
   

Checking SELinux (RHEL/CentOS/Fedora)

1. Check status:

   sestatus
   

   
   If Enabled, check the context of ~/.ssh:

   ls -laZ ~/.ssh
   

   
   Files should have ssh_home_t and the directory ssh_home_dir_t.
2. Restore context:

   sudo restorecon -Rv ~/.ssh
   

3. If the problem persists, temporarily disable SELinux for diagnosis:

   sudo setenforce 0
   

   
   Do not leave it disabled! After diagnosis, find the proper solution (correct context or policy).

Checking AppArmor (Ubuntu/Debian)

1. Check the sshd profile:

   sudo aa-status | grep sshd
   

   
   If the profile is in enforce mode, try switching to complain:

   sudo aa-complain /etc/apparmor.d/usr.sbin.sshd
   

   
   Restart sshd and test the connection.
2. If it works, configure the profile correctly or leave it in complain if there is no threat.

Method 6: Checking Shell and User Status

1. Ensure the user has a shell:

   grep ^username: /etc/passwd
   

   
   The last field should be /bin/bash, /bin/sh, or another valid shell from /etc/shells. If it is /usr/sbin/nologin or /bin/false, change it:

   sudo chsh -s /bin/bash username
   

2. Check if the user is locked:

   sudo passwd -S username
   

   
   If the status is L (locked), unlock it:

   sudo passwd -u username
   

3. Check if the password has expired:

   sudo chage -l username
   

   
   If the password has expired (Password expires), reset it:

   sudo passwd username
   

Prevention

• Use SSH keys instead of passwords — they are more reliable and convenient.
• Regularly update OpenSSH to receive vulnerability fixes:

  sudo apt update && sudo apt upgrade openssh-server   # Debian/Ubuntu
  sudo yum update openssh-server                       # RHEL/CentOS 7
  sudo dnf update openssh-server                       # RHEL/CentOS 8+/Fedora
  

• Configure sshd_config securely: disable PasswordAuthentication if using keys; restrict access via AllowUsers.
• Monitor logs (/var/log/auth.log or /var/log/secure) for suspicious attempts.
• Use a firewall (ufw, firewalld, iptables) to restrict port 22 to only trusted IPs.
• Do not use root access directly — log in as a regular user and elevate privileges with sudo.
• Regularly check permissions on ~/.ssh and authorized_keys after system changes.
• When using SELinux/AppArmor, do not disable them; configure policies correctly.

If the issue is not resolved, check network settings (NAT, cloud security groups) and PAM authentication (/etc/pam.d/sshd). As a last resort, temporarily increase the logging level in sshd_config (LogLevel VERBOSE) and restart sshd for more details.