How to fix Permission denied, please try again. in SSH

Check that you're using the correct SSH connection command. The syntax is:

ssh username@hostname

Common mistakes:
- Typing just 'ssh hostname' (uses current local user, may not exist on server)
- Typographical errors in the hostname or username
- Using the server's IP address instead of hostname (or vice versa)

To check what user you are logging in as:

whoami

Verify the user exists on the server:

ssh username@hostname "id"

If the user doesn't exist, create it on the server (as root or an admin user):

sudo useradd newuser

If you're using password-based authentication, ensure your password is entered correctly.

Things to check:
- Caps Lock is NOT enabled (SSH is case-sensitive)
- No extra spaces before or after the password
- The keyboard layout matches what you expect (especially on remote systems)
- Your password has not expired on the server

If you're unsure of the password, change it on the server (as root):

sudo passwd username

Or reset it from a different terminal where you have access.

If you know the credentials are correct but keep getting denied, password authentication might be disabled.

Login to the SSH server (using another method if available) and check the SSH configuration:

sudo grep -i passwordauthentication /etc/ssh/sshd_config

If it shows:

PasswordAuthentication no

Enable password authentication:

sudo sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Note: The default is usually 'yes', so if the line doesn't exist or is commented out, password auth is enabled. If it explicitly says 'no', you need to change it.

For more secure and reliable authentication, use SSH keys instead of passwords.

On your local machine, generate an SSH key pair:

ssh-keygen -t ed25519 -C "[email protected]"

Press Enter to use the default location (~/.ssh/id_ed25519), and optionally set a passphrase.

Copy your public key to the server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@hostname

Or manually add it:

cat ~/.ssh/id_ed25519.pub | ssh username@hostname "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Now test the connection:

ssh -i ~/.ssh/id_ed25519 username@hostname

If using an RSA key, replace 'ed25519' with 'rsa':

ssh-keygen -t rsa -b 4096 -C "[email protected]"

SSH is strict about file permissions. Incorrect permissions on ~/.ssh or ~/.ssh/authorized_keys will cause authentication to fail silently.

On the server, fix permissions:

# Fix ~/.ssh directory (must be 700 - rwx------)
chmod 700 ~/.ssh

# Fix authorized_keys file (must be 600 - rw-------)
chmod 600 ~/.ssh/authorized_keys

# Fix home directory (should not be writable by others)
chmod 755 ~

Verify permissions are correct:

ls -la ~
ls -la ~/.ssh
ls -la ~/.ssh/authorized_keys

Expected output:
- Home directory: drwxr-xr-x
- .ssh directory: drwx------
- authorized_keys: -rw-------

Ensure your public key was actually added to the server's ~/.ssh/authorized_keys file.

On the server, check the contents:

cat ~/.ssh/authorized_keys

You should see one or more lines starting with 'ssh-rsa', 'ssh-ed25519', or similar.

On your local machine, verify your public key:

cat ~/.ssh/id_ed25519.pub

Compare these - they should match (the authorized_keys entry should be identical to your public key, plus possibly a comment at the end).

If your key is not in authorized_keys, add it:

echo "$(cat ~/.ssh/id_ed25519.pub)" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Use verbose mode to see exactly which authentication methods the server tried:

ssh -vvv username@hostname

This will show detailed output like:

debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Offering public key: /home/user/.ssh/id_rsa
debug1: Server accepted key but wanted different sign types

Look for lines mentioning:
- Which keys were tried
- Which authentication methods the server offered
- Why each method failed

On the server side, check SSH logs:

# Ubuntu/Debian
sudo tail -f /var/log/auth.log | grep sshd

# CentOS/RHEL
sudo tail -f /var/log/secure | grep sshd

This shows server-side rejection reasons, which may be more specific than the client error message.

If multiple users can't connect, the problem is likely server-side SSH configuration.

On the server, check the full sshd_config:

sudo sshd -T

This outputs the effective configuration. Look for:

passwordauthentication yes
pubkeyauthentication yes
permitrootlogin yes  (or without-password)

If you made changes to /etc/ssh/sshd_config, verify syntax before restarting:

sudo sshd -t

Then restart SSH:

sudo systemctl restart sshd

After restarting, try connecting again.