SSH Authentication Failure: How to Fix Access Errors in Linux

What an SSH Authentication Error Means

An SSH authentication error occurs when the client (your local machine) cannot verify its identity to the remote server. Typical error messages:

Permission denied (publickey,password).

or

Authentication failed.

This error blocks the connection at the security level, even if network parameters (host, port) are correct. The problem can be on the client side (incorrect keys/password) or the server side (misconfigured settings or permissions).

Common Causes

1. Incorrect username or password — you specified a non-existent user or made a typo in the password.
2. Missing or incorrect SSH key — the public key isn't added to ~/.ssh/authorized_keys on the server, or the wrong private key is being used.
3. Incorrect SSH file permissions on the server — permissions on ~/.ssh or ~/.ssh/authorized_keys are too open (e.g., 777), which is considered a security risk.
4. Password authentication is disabled on the server — PasswordAuthentication no is set in /etc/ssh/sshd_config.
5. Public key has incorrect formatting — for example, it was added to authorized_keys with extra spaces or line breaks.
6. SSH agent hasn't loaded the key — the key exists but isn't added to ssh-agent, so the client can't find it.
7. Key conflict — multiple keys exist in authorized_keys on the server, and the server rejects the one provided.

Troubleshooting Steps

Method 1: Verify and Correct Credentials

Step 1: Ensure the username is correct. For a local user john on server 192.168.1.10, the command should be:

ssh john@192.168.1.10

Step 2: If using a password, enter it carefully. Note that password characters aren't displayed as you type (this is normal).

Step 3: When using SSH keys:

• Verify the private key exists (typically ~/.ssh/id_rsa or ~/.ssh/id_ed25519).
• Load the key into ssh-agent:

  eval "$(ssh-agent -s)"
  ssh-add ~/.ssh/id_rsa
  

• Ensure the corresponding public key (with .pub extension) is added to ~/.ssh/authorized_keys on the server. You can copy the key with:

  ssh-copy-id -i ~/.ssh/id_rsa.pub user@host
  

Method 2: Fix Permissions on the Server

Incorrect permissions are the most common cause. On the server (if you have access), run:

# Navigate to the target user's home directory
cd /home/username

# Set correct permissions
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

# Ensure the owner is the target user
chown -R username:username .ssh

⚠️ Important: If the home directory (/home/username) is writable by other users (permissions 777 or group write), SSH may refuse authentication. Fix permissions with: chmod 755 /home/username (or 750).

Method 3: Check and Configure SSH Server Settings

On the server, open the configuration file:

sudo nano /etc/ssh/sshd_config

Ensure the following lines are uncommented (no # at the start) and have the correct values:

# For password authentication
PasswordAuthentication yes

# For key-based authentication
PubkeyAuthentication yes

# Allow login for specific user (optional)
AllowUsers username

💡 Tip: If you're configuring a server for the first time, temporarily leave both methods enabled (yes) to test the connection. After successfully setting up keys, you can disable passwords (PasswordAuthentication no) for security.

Restart the SSH service:

sudo systemctl restart sshd
# Or on older systems:
# sudo service ssh restart

Method 4: Explicitly Specify the Key When Connecting

If you have multiple keys, SSH might try to use the wrong one. Specify the path to the correct private key:

ssh -i ~/.ssh/id_ed25519_custom user@host

You can also create or edit ~/.ssh/config on the client:

Host myserver
    HostName 192.168.1.10
    User username
    IdentityFile ~/.ssh/id_ed25519_custom

After this, simply run ssh myserver.

Method 5: Analyze SSH Server Logs

If the previous steps didn't help, check the server logs. They contain the exact reason for the rejection.

On most Linux systems:

sudo tail -f /var/log/auth.log
# For CentOS/RHEL/Fedora:
# sudo tail -f /var/log/secure

Connect from the client and watch the logs in real time. Typical messages:

• Failed publickey for user from 192.168.1.5 port 56789 ssh2: RSA SHA256:... — key not accepted.
• Failed password for user from 192.168.1.5 port 56789 ssh2 — incorrect password.
• Authentication refused: bad ownership or modes for directory /home/user — incorrect permissions.

Prevention

1. Use secure permissions — always set chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys on the server.
2. Disable password authentication after setting up keys — this protects against brute-force attacks.
3. Keep OpenSSH updated — monitor security updates: sudo apt update && sudo apt upgrade openssh-server (Ubuntu/Debian) or sudo yum update openssh-server (CentOS).
4. Use strong keys — minimum 3072 bits for RSA or Ed25519.
5. Configure a firewall — restrict port 22 access to trusted IP addresses only:

   sudo ufw allow from 192.168.1.0/24 to any port 22
   

6. Monitor logs — set up regular review of /var/log/auth.log or integration with a SIEM system.

# Example: Check server configuration without restarting
sudo sshd -t
# If output is empty — configuration is syntactically valid.