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.
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
Log into the server (using password auth if available) and check the authorized_keys file:
cat ~/.ssh/authorized_keysYour 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:
# 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_keysMake sure each key is on its own line with no extra spaces or line breaks.
sshd is very strict about file permissions. Incorrect permissions will cause key authentication to fail silently:
# 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:
# Home directory should not be world-writable
chmod go-w ~Different SSH servers support different key types. Verify your key type:
# 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-ed25519If using an old key type like RSA on a modern server, consider generating Ed25519 keys instead:
ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@serverOn the server, check which algorithms are accepted in sshd_config:
sudo grep PubkeyAcceptedAlgorithms /etc/ssh/sshd_configIf the line is commented out, all standard algorithms are supported. If it's restricted, update it to include your key type:
# 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 sshdCheck if the user is allowed by SSH access controls. In sshd_config, these rules can block even valid keys:
sudo grep -E "^(AllowUsers|DenyUsers|AllowGroups|DenyGroups)" /etc/ssh/sshd_configIf you see restrictive rules, verify the user is included:
AllowUsers - Only listed users can log in. Add the user if missing:
sudo sed -i 's/^AllowUsers.*/AllowUsers your-username/' /etc/ssh/sshd_configDenyUsers - Listed users cannot log in. Make sure the user is not listed:
# Remove the user from DenyUsers
sudo sed -i 's/^DenyUsers \(.*\)your-username\(.*\)/DenyUsers \1\2/' /etc/ssh/sshd_configAllowGroups - Only listed groups can log in. Ensure the user's group is included:
# Check the user's groups
id your-username
# Update sshd_config if needed
sudo sed -i 's/^AllowGroups.*/AllowGroups your-group/' /etc/ssh/sshd_configAfter making changes, reload sshd:
sudo systemctl reload sshd
# or
sudo service sshd reloadCheck if the server allows public key authentication:
sudo grep PubkeyAuthentication /etc/ssh/sshd_configIt should say:
PubkeyAuthentication yesIf it's set to no, enable it:
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 sshdEnable detailed sshd logging to see exactly why authentication is failing:
# 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 sshdNow tail the logs while attempting to connect:
# 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.
Use verbose mode on the client to see which key is being attempted:
ssh -vvv user@server 2>&1 | grep -A 5 "Offering public key"Look for output like:
Offering public key: /home/user/.ssh/id_ed25519 ED25519 SHA256:xxxxx
Server also accepted RSA key, but wanted a different algorithmIf the wrong key is being tried, force the correct one:
ssh -i ~/.ssh/id_ed25519 -vvv user@serverOr configure it permanently in ~/.ssh/config:
Host server
User your-username
HostName your-server.com
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yesSELinux Blocking SSH Keys: On systems with SELinux enabled, incorrect file contexts can prevent sshd from reading authorized_keys:
# Check and fix SELinux contexts
sudo restorecon -R ~/.ssh
# Verify
ls -Z ~/.ssh/authorized_keysCustom AuthorizedKeysFile Location: Some servers use non-standard locations for authorized_keys. Check sshd_config:
sudo grep AuthorizedKeysFile /etc/ssh/sshd_configDefault 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:
# 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_keyFail2ban Lockout: If multiple failed attempts trigger fail2ban or another rate limiter, the IP may be temporarily blocked. Check:
sudo fail2ban-client status sshd
sudo iptables -L -n | grep DROPLoad key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH
Connection closed by UNKNOWN port 65535
How to fix 'Connection closed by UNKNOWN port 65535' in SSH
Offending ECDSA key in /home/user/.ssh/known_hosts:line
How to fix "Offending ECDSA key in known_hosts" in SSH