How to fix Access denied in SSH

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

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

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

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.

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:

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

If it shows PasswordAuthentication no, enable it:

# 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:

ssh username@hostname
# Enter password when prompted

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

# 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:

# On the remote server
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 755 ~/  # if home directory is too permissive

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

# On your local machine, display your public key
cat ~/.ssh/id_rsa.pub
# or for ED25519 keys
cat ~/.ssh/id_ed25519.pub

# 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:

# 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

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

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:

sudo vi /etc/ssh/sshd_config

Add or modify lines:

AllowUsers alice bob yourUsername
# or
DenyUsers hacker

Then restart SSH:

sudo systemctl restart ssh
# or on some systems:
sudo service sshd restart

The user account might be locked or disabled:

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

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

sudo passwd -u username

Also verify the user's shell is valid:

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

If it shows nologin, change the shell:

sudo usermod -s /bin/bash username

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

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).