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

SSHBEGINNERMEDIUMUpdated Jan 4, 2026· 360 views

This SSH error appears when authentication fails due to incorrect credentials, disabled password authentication, or mismatched SSH keys. It typically occurs when logging in with password or public key authentication. Resolve it by verifying credentials, enabling password authentication on the server, or ensuring your SSH keys are properly configured.

Quick fix

Fixes Permission denied, please try again.

ssh username@hostname
  1. Verify you are using the correct username and hostname
  2. Verify your password is correct
  3. Check if password authentication is enabled on the server
  4. Set up SSH key-based authentication
ssh — error
ssh username@hostname
Permission denied, please try again.

What this error means

The "Permission denied, please try again" error is a generic authentication failure message from SSH. It indicates that the SSH server rejected your authentication attempt, but the server is allowing you to retry. This differs from a connection error—the connection succeeds, but authentication fails. Unlike the more specific "Permission denied (publickey)" error, this generic message can result from multiple causes: 1. **Wrong password**: You entered an incorrect password for password-based authentication 2. **Password authentication disabled**: The SSH server has PasswordAuthentication set to "no" in sshd_config 3. **Key authentication failed**: Your public key is not in the server's authorized_keys, or your key doesn't match 4. **User doesn't exist**: The username doesn't exist on the server 5. **SSH key permissions incorrect**: File permissions on ~/.ssh or ~/.ssh/authorized_keys are wrong The server will let you retry a limited number of times (default: 3) before disconnecting completely with "No more authentication methods to try."

Typical symptoms

  • SSH connection prompt asks for password or passphrase, then displays 'Permission denied, please try again'
  • Attempting multiple times with the same password/key keeps failing
  • Pressing Ctrl+C after several retries disconnects with 'Too many authentication failures'
  • Command 'ssh user@host' fails, but 'ssh -v user@host' shows authentication was attempted
  • Other users or systems can connect to the same SSH server without issue
  • The server connection appears to work (you see the password prompt), but login fails

Common causes

  1. You are using the wrong password or passphrase for the user account
  2. The SSH server has password authentication disabled (PasswordAuthentication no in sshd_config)
  3. Your SSH public key is not added to the server's ~/.ssh/authorized_keys file
  4. The user account doesn't exist on the server or is spelled incorrectly
  5. File permissions are incorrect on ~/.ssh directory (should be 700) or authorized_keys file (should be 600)
  6. The SSH server only allows public key authentication, but you're attempting password login
  7. Your private key doesn't match any public key in the server's authorized_keys
  8. The server's sshd service has been misconfigured or recently restarted

How to fix "Permission denied, please try again."

1Verify you are using the correct username and hostname

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

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

bash
whoami

Verify the user exists on the server:

bash
ssh username@hostname "id"

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

bash
sudo useradd newuser
2Verify your password is correct

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

bash
sudo passwd username

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

3Check if password authentication is enabled on the server

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:

bash
sudo grep -i passwordauthentication /etc/ssh/sshd_config

If it shows:

bash
PasswordAuthentication no

Enable password authentication:

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

4Set up SSH key-based authentication

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

On your local machine, generate an SSH key pair:

bash
ssh-keygen -t ed25519 -C "your_email@example.com"

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

Copy your public key to the server:

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

Or manually add it:

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

Now test the connection:

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

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

bash
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
5Fix SSH directory and file permissions

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:

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

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

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

6Verify your public key is in authorized_keys

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

On the server, check the contents:

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

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

bash
echo "$(cat ~/.ssh/id_ed25519.pub)" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
7Enable SSH verbose mode to debug

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

bash
ssh -vvv username@hostname

This will show detailed output like:

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

bash
# 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.

8Check SSH server configuration

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

On the server, check the full sshd_config:

bash
sudo sshd -T

This outputs the effective configuration. Look for:

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

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

bash
sudo sshd -t

Then restart SSH:

bash
sudo systemctl restart sshd

After restarting, try connecting again.

Advanced notes

Why "Permission denied, please try again" is generic: SSH servers intentionally return the same error message for multiple failure scenarios. This is a security practice to avoid leaking information about which users exist on a system. An attacker could use different error messages to enumerate valid usernames.

Retry limits: The SSH server will allow 3 password/key authentication attempts by default (controlled by MaxAuthTries in sshd_config). After exceeding this limit, you'll see "Too many authentication failures" and must wait before retrying.

SSH agent and key forwarding: If using SSH agent forwarding to jump through servers (ssh -A), ensure your agent has your keys loaded:

bash
ssh-add ~/.ssh/id_ed25519
ssh-add -l  # List loaded keys

SELinux/AppArmor issues: On systems with SELinux or AppArmor enabled, the SSH configuration may be restricted at the OS level. If all the above steps work locally but fail on the server, check:

bash
sudo getenforce  # Check SELinux status
sudo systemctl status apparmor  # Check AppArmor status

Root login: Some servers disable root login (PermitRootLogin no). If trying to login as root fails but a regular user works, you'll need to create a regular user account first or enable root login on the server.

Expect tool: For scripting SSH connections where password entry is needed, use expect (not recommended for production - use keys instead):

bash
expect -c "spawn ssh user@host; expect "password:"; send "mypassword\r"; interact"

However, storing passwords in scripts is a security risk. SSH keys are always preferable.

Frequently asked questions

What does "Permission denied, please try again." mean?
The "Permission denied, please try again" error is a generic authentication failure message from SSH. It indicates that the SSH server rejected your authentication attempt, but the server is allowing you to retry. This differs from a connection error—the connection succeeds, but authentication fails.
How do I fix "Permission denied, please try again."?
This SSH error appears when authentication fails due to incorrect credentials, disabled password authentication, or mismatched SSH keys. It typically occurs when logging in with password or public key authentication. Resolve it by verifying credentials, enabling password authentication on the server, or ensuring your SSH keys are properly configured.
What causes "Permission denied, please try again."?
You are using the wrong password or passphrase for the user account The SSH server has password authentication disabled (PasswordAuthentication no in sshd_config) Your SSH public key is not added to the server's ~/.ssh/authorized_keys file
Is the "Permission denied, please try again." error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading