How to fix Access denied in SSH

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 558 views

The SSH "Access denied" error occurs when the SSH server rejects your authentication attempt. This is usually due to incorrect credentials, misconfigured keys, disabled authentication methods, or account/group restrictions on the server.

Quick fix

Fixes Access denied

ssh username@hostname
# or with explicit port
ssh -p 22 username@hostname
  1. Verify the correct username and hostname
  2. Test with verbose mode to see detailed authentication attempts
  3. Enable password authentication if using keys
  4. Check and fix authorized_keys permissions on server
ssh — error
ssh username@hostname
# or with explicit port
ssh -p 22 username@hostname
Access denied

What this error means

SSH "Access denied" is a generic authentication failure message that appears after the SSH client successfully connects to the server but fails during the authentication phase. The server's SSH daemon (sshd) has evaluated your provided credentials—whether public key, password, or other method—and determined they don't match any accepted authentication method or the user account is restricted. This differs from connection errors (like "Connection refused") because the server is reachable; it simply won't grant access.

Typical symptoms

  • SSH connection prompt appears but immediately rejects login
  • Password prompt shows but rejects correct password
  • Private key exists but server refuses it
  • Manual SSH works from one machine but not another
  • Specific user accounts can't log in while others can
  • Access denied without any detailed error message about which method failed

Common causes

  1. Incorrect username or password provided to the SSH command
  2. Public key on client doesn't match the public key in server's authorized_keys file
  3. authorized_keys file has wrong permissions (should be 600)
  4. Home directory on server has overly permissive permissions (e.g., 777)
  5. User account is disabled or locked on the server
  6. User not listed in AllowUsers directive in sshd_config (whitelist)
  7. User listed in DenyUsers directive in sshd_config (blacklist)
  8. User's group not in AllowGroups or listed in DenyGroups in sshd_config
  9. Password authentication disabled in sshd_config but no key provided
  10. Public key authentication disabled in sshd_config
  11. SSH server restarted and authorized_keys wasn't preserved
  12. Using wrong SSH key (multiple keys on system and using non-matching one)

How to fix "Access denied"

1Verify the correct username and hostname

First, double-check your SSH command syntax. The most common cause is using the wrong username.

bash
ssh username@hostname
# or with explicit port
ssh -p 22 username@hostname

If unsure of the correct username, ask your system administrator. Common default usernames:
- Linux/Ubuntu: ubuntu, admin, root
- Amazon Linux: ec2-user
- CentOS/RHEL: centos, root
- Debian: debian
- macOS: your local username

2Test with verbose mode to see detailed authentication attempts

Enable verbose output to see which authentication methods are being attempted and where the failure occurs:

bash
ssh -vvv username@hostname

Look for lines like:
- debug1: Offering public key - Client is trying public key auth
- debug1: Authentications that can continue: publickey,password - Server's accepted methods
- Permission denied (publickey) - Server rejected that method

This reveals exactly which authentication method is failing.

3Enable password authentication if using keys

If you don't have an SSH key set up, try password authentication directly. First, ensure the server allows passwords by checking sshd_config on the server:

bash
# On the remote server
sudo grep PasswordAuthentication /etc/ssh/sshd_config

If it shows PasswordAuthentication no, enable it:

bash
# On the remote server
sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication yes/' /etc/ssh/sshd_config
sudo systemctl restart ssh  # or 'service sshd restart'

Then retry from your client:

bash
ssh username@hostname
# Enter password when prompted
4Check and fix authorized_keys permissions on server

If using public key authentication, the authorized_keys file and parent directory must have correct permissions:

bash
# On the remote server, as the user trying to log in
ls -la ~/.ssh/authorized_keys
ls -la ~/.ssh/
ls -la ~/

Expected output:
- authorized_keys should be: -rw------- 1 username username (600)
- .ssh directory should be: drwx------ 2 username username (700)
- home directory should be: drwxr-xr-x 2 username username (755, NOT 777)

Fix permissions if needed:

bash
# On the remote server
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 755 ~/  # if home directory is too permissive
5Verify your public key is in authorized_keys

If using public key auth, your public key must exist on the server:

bash
# On your local machine, display your public key
cat ~/.ssh/id_rsa.pub
# or for ED25519 keys
cat ~/.ssh/id_ed25519.pub
bash
# On the remote server, check if it's in authorized_keys
cat ~/.ssh/authorized_keys

Compare the output. If your public key isn't there, add it:

bash
# Option 1: Use ssh-copy-id (easiest, if password auth works)
ssh-copy-id -i ~/.ssh/id_rsa.pub username@hostname

# Option 2: Manually append the key (if you have access another way)
echo "your_public_key_content" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
6Check sshd_config for user restrictions

The server's SSH configuration may explicitly allow or deny your user. Check on the remote server:

bash
sudo grep -E 'AllowUsers|DenyUsers|AllowGroups|DenyGroups' /etc/ssh/sshd_config

If you see:
- AllowUsers alice bob - Only alice and bob can log in. Add yourself.
- DenyUsers hacker - These users are explicitly blocked.

To fix, edit the config:

bash
sudo vi /etc/ssh/sshd_config

Add or modify lines:

bash
AllowUsers alice bob yourUsername
# or
DenyUsers hacker

Then restart SSH:

bash
sudo systemctl restart ssh
# or on some systems:
sudo service sshd restart
7Ensure the user account is enabled on the server

The user account might be locked or disabled:

bash
# On the remote server, check account status
sudo passwd -S username

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

bash
sudo passwd -u username

Also verify the user's shell is valid:

bash
# Should show /bin/bash or /bin/sh, not /usr/sbin/nologin
grep username /etc/passwd

If it shows nologin, change the shell:

bash
sudo usermod -s /bin/bash username
8Try a different authentication method

If public key authentication is failing, explicitly request password-based auth:

bash
ssh -o PubkeyAuthentication=no username@hostname
# This forces password auth only

If this works, it means:
- Your key isn't the problem
- Password auth is available
- Check the authorized_keys file again

Alternatively, if password fails but key works, ensure password auth is enabled on the server (see Step 3).

Advanced notes

SELinux and AppArmor: On servers with SELinux or AppArmor enabled, even correct credentials can be rejected. Check enforcement status:

bash
sudo getenforce  # For SELinux
sudo aa-status   # For AppArmor

If either is enforcing, SSH might be blocked. Check logs:

bash
sudo tail /var/log/auth.log  # Debian/Ubuntu
sudo tail /var/log/secure    # CentOS/RHEL

Group-based access: If using group-based restrictions (AllowGroups, DenyGroups), ensure your user is in the correct group:

bash
groups username

Add user to group if needed:

bash
sudo usermod -aG groupname username

PAM (Pluggable Authentication Modules): Some systems use PAM for authentication. If sshd_config looks correct but you still can't access, check PAM configuration:

bash
sudo grep -r session /etc/pam.d/sshd

Multiple keys: If you have multiple private keys on your system, SSH tries them in order. If a key with too many failed attempts is tried first, the server may reject all subsequent authentication attempts. Use:

bash
ssh -i /path/to/correct/key username@hostname

to explicitly specify which key to use.

Frequently asked questions

What does "Access denied" mean?
SSH "Access denied" is a generic authentication failure message that appears after the SSH client successfully connects to the server but fails during the authentication phase. The server's SSH daemon (sshd) has evaluated your provided credentials—whether public key, password, or other method—and determined they don't match any accepted authentication method or the user account is restricted. This differs from connection errors (like "Connection refused") because the server is reachable; it simply won't grant access.
How do I fix "Access denied"?
The SSH "Access denied" error occurs when the SSH server rejects your authentication attempt. This is usually due to incorrect credentials, misconfigured keys, disabled authentication methods, or account/group restrictions on the server.
What causes "Access denied"?
Incorrect username or password provided to the SSH command Public key on client doesn't match the public key in server's authorized_keys file authorized_keys file has wrong permissions (should be 600)
Is the "Access denied" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading