How to fix Failed publickey for user from hostname port XXXXX ssh2 in SSH

SSHINTERMEDIATEMEDIUMUpdated Jan 4, 2026· 218 views

The "Failed publickey for user" message appears in sshd logs when an SSH client attempts public key authentication but the server rejects the key. This indicates a mismatch between the client's key and the server's authorized_keys, or the server doesn't recognize the key algorithm.

Quick fix

Fixes Failed publickey for user from hostname port XXXXX ssh2

cat ~/.ssh/authorized_keys
  1. Verify the public key is in authorized_keys on the server
  2. Fix file permissions on the server
  3. Check the SSH key algorithm is supported
  4. Ensure the user is allowed to authenticate
ssh — error
cat ~/.ssh/authorized_keys
Failed publickey for user from hostname port XXXXX ssh2

What this error means

This is a server-side log message from the SSH daemon (sshd) that indicates: 1. A client connected and presented a public key for authentication 2. The server attempted to validate the key against its authorized_keys file 3. The validation failed, and the connection was rejected This is NOT the same as "Permission denied (publickey)" on the client side. That client-side error means the authentication failed completely. This server-side message is logged when sshd specifically attempted publickey authentication and the key didn't match anything in authorized_keys. The failure could be due to: - The public key not being in the remote user's ~/.ssh/authorized_keys file - The public key format being incompatible with the server's SSH version - The SSH key algorithm not being in the server's PubkeyAcceptedAlgorithms list - File permissions preventing sshd from reading authorized_keys - The key being in authorized_keys but on a different line/format than expected

Typical symptoms

  • SSH connections fail with 'Permission denied (publickey)' on the client
  • Server log (/var/log/auth.log or /var/log/secure) shows 'Failed publickey for user' messages
  • Multiple failed attempts from the same IP address
  • Works with password authentication but not key-based
  • Works with one username but not another on the same server

Common causes

  1. The public key has not been added to the user's ~/.ssh/authorized_keys file on the server
  2. The public key in authorized_keys is malformed or corrupted (extra whitespace, line breaks, etc.)
  3. The SSH key algorithm (RSA, ECDSA, Ed25519) is not supported by the server's sshd configuration
  4. File permissions on ~/.ssh or authorized_keys are incorrect, preventing sshd from reading the keys
  5. The wrong public key is in authorized_keys (e.g., an old key when a new one was generated)
  6. The server's sshd_config restricts which key types are accepted (PubkeyAcceptedAlgorithms setting)
  7. The user account is restricted by AllowUsers, DenyUsers, AllowGroups, or DenyGroups in sshd_config
  8. The authorized_keys file is in the wrong location due to custom AuthorizedKeysFile setting in sshd_config

How to fix "Failed publickey for user from hostname port XXXXX ssh2"

1Verify the public key is in authorized_keys on the server

Log into the server (using password auth if available) and check the authorized_keys file:

bash
cat ~/.ssh/authorized_keys

Your public key should appear as a single, unbroken line starting with ssh-rsa, ecdsa-sha2, or ssh-ed25519.

If your key is not there, copy it from your client machine and add it:

bash
# On the server, edit the file
nano ~/.ssh/authorized_keys

# Or append from the client (using password auth first)
echo "your-public-key-content" >> ~/.ssh/authorized_keys

Make sure each key is on its own line with no extra spaces or line breaks.

2Fix file permissions on the server

sshd is very strict about file permissions. Incorrect permissions will cause key authentication to fail silently:

bash
# Fix directory permissions
chmod 700 ~/.ssh

# Fix authorized_keys permissions (must be 600 or 644)
chmod 600 ~/.ssh/authorized_keys

# Verify
ls -la ~/.ssh/

Expected output:
- drwx------ (700) for ~/.ssh directory
- -rw------- (600) or -rw-r--r-- (644) for authorized_keys

If the home directory itself has wrong permissions, sshd won't trust the SSH keys:

bash
# Home directory should not be world-writable
chmod go-w ~
3Check the SSH key algorithm is supported

Different SSH servers support different key types. Verify your key type:

bash
# On the client, check your key type
ssh-keyscan -p 22 your-server.com | grep ssh

# Or check the public key file
head -n 1 ~/.ssh/id_rsa.pub  # Shows: ssh-rsa, ecdsa-sha2-nistp256, or ssh-ed25519

If using an old key type like RSA on a modern server, consider generating Ed25519 keys instead:

bash
ssh-keygen -t ed25519 -C "your-email@example.com"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

On the server, check which algorithms are accepted in sshd_config:

bash
sudo grep PubkeyAcceptedAlgorithms /etc/ssh/sshd_config

If the line is commented out, all standard algorithms are supported. If it's restricted, update it to include your key type:

bash
# For example, to accept Ed25519 and modern RSA keys:
sudo sed -i 's/#PubkeyAcceptedAlgorithms.*/PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256/' /etc/ssh/sshd_config
sudo systemctl restart sshd
4Ensure the user is allowed to authenticate

Check if the user is allowed by SSH access controls. In sshd_config, these rules can block even valid keys:

bash
sudo grep -E "^(AllowUsers|DenyUsers|AllowGroups|DenyGroups)" /etc/ssh/sshd_config

If you see restrictive rules, verify the user is included:

AllowUsers - Only listed users can log in. Add the user if missing:

bash
sudo sed -i 's/^AllowUsers.*/AllowUsers your-username/' /etc/ssh/sshd_config

DenyUsers - Listed users cannot log in. Make sure the user is not listed:

bash
# Remove the user from DenyUsers
sudo sed -i 's/^DenyUsers \(.*\)your-username\(.*\)/DenyUsers \1\2/' /etc/ssh/sshd_config

AllowGroups - Only listed groups can log in. Ensure the user's group is included:

bash
# Check the user's groups
id your-username

# Update sshd_config if needed
sudo sed -i 's/^AllowGroups.*/AllowGroups your-group/' /etc/ssh/sshd_config

After making changes, reload sshd:

bash
sudo systemctl reload sshd
# or
sudo service sshd reload
5Verify PubkeyAuthentication is enabled

Check if the server allows public key authentication:

bash
sudo grep PubkeyAuthentication /etc/ssh/sshd_config

It should say:

bash
PubkeyAuthentication yes

If it's set to no, enable it:

bash
sudo sed -i 's/^#PubkeyAuthentication.*/PubkeyAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^PubkeyAuthentication no/PubkeyAuthentication yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
6Monitor sshd logs for detailed error messages

Enable detailed sshd logging to see exactly why authentication is failing:

bash
# Check current log level
sudo grep LogLevel /etc/ssh/sshd_config

# Increase verbosity (VERBOSE or DEBUG)
sudo sed -i 's/^#LogLevel.*/LogLevel VERBOSE/' /etc/ssh/sshd_config
sudo sed -i 's/^LogLevel.*/LogLevel VERBOSE/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Now tail the logs while attempting to connect:

bash
# On the server
sudo tail -f /var/log/auth.log | grep sshd

# From another terminal, attempt connection
ssh user@server

# Look for detailed error messages like:
# - "key_from_blob: bad key blob"
# - "Received disconnect"
# - "Invalid key format"
# - "Algorithm negotiation failed"

These detailed messages will help identify the exact cause.

7Verify the client is sending the correct key

Use verbose mode on the client to see which key is being attempted:

bash
ssh -vvv user@server 2>&1 | grep -A 5 "Offering public key"

Look for output like:

bash
Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:xxxxx
Server also accepted RSA key, but wanted a different algorithm

If the wrong key is being tried, force the correct one:

bash
ssh -i ~/.ssh/id_ed25519 -vvv user@server

Or configure it permanently in ~/.ssh/config:

bash
Host server
  User your-username
  HostName your-server.com
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

Advanced notes

SELinux Blocking SSH Keys: On systems with SELinux enabled, incorrect file contexts can prevent sshd from reading authorized_keys:

bash
# Check and fix SELinux contexts
sudo restorecon -R ~/.ssh

# Verify
ls -Z ~/.ssh/authorized_keys

Custom AuthorizedKeysFile Location: Some servers use non-standard locations for authorized_keys. Check sshd_config:

bash
sudo grep AuthorizedKeysFile /etc/ssh/sshd_config

Default is ~/.ssh/authorized_keys, but it could be in a system-wide directory or have tokens like %u (username) or %h (home directory).

Rootless SSH: If sshd is running as a non-root user, ~/.ssh paths and permissions are even more critical. Ensure the sshd process user can read all necessary files.

Key Format Issues: Ensure keys are in OpenSSH format, not PEM format:

bash
# Check key format (should start with BEGIN OPENSSH PRIVATE KEY)
head -n 1 ~/.ssh/id_ed25519

# Convert PEM to OpenSSH format if needed
ssh-keygen -p -N "" -m pem -f ~/.ssh/old_key
ssh-keygen -p -N "" -m RFC4716 -f ~/.ssh/old_key

Fail2ban Lockout: If multiple failed attempts trigger fail2ban or another rate limiter, the IP may be temporarily blocked. Check:

bash
sudo fail2ban-client status sshd
sudo iptables -L -n | grep DROP

Frequently asked questions

What does "Failed publickey for user from hostname port XXXXX ssh2" mean?
This is a server-side log message from the SSH daemon (sshd) that indicates: 1. A client connected and presented a public key for authentication 2. The server attempted to validate the key against its authorized_keys file 3.
How do I fix "Failed publickey for user from hostname port XXXXX ssh2"?
The "Failed publickey for user" message appears in sshd logs when an SSH client attempts public key authentication but the server rejects the key. This indicates a mismatch between the client's key and the server's authorized_keys, or the server doesn't recognize the key algorithm.
What causes "Failed publickey for user from hostname port XXXXX ssh2"?
The public key has not been added to the user's ~/.ssh/authorized_keys file on the server The public key in authorized_keys is malformed or corrupted (extra whitespace, line breaks, etc.) The SSH key algorithm (RSA, ECDSA, Ed25519) is not supported by the server's sshd configuration
Is the "Failed publickey for user from hostname port XXXXX ssh2" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading