Almost every article about this error tells you to check your private key and regenerate it. That is the right advice about a third of the time. The rest of the time the key is perfectly good and the server is quietly refusing it, and the only message you get on the client is the same unhelpful Permission denied (publickey). The server knows exactly why it refused you. The trick is making it say so.
Get the client to show what it is offering
Run the connection with verbose output so you can see which keys are tried and how the server responds. This tells you whether the problem is the key itself or the server's verdict on it:
ssh -vvv user@server.example.comLook for the lines saying which identity files are being offered and whether the server accepted any. If your key never appears, the client is not offering it, which is a client-side fix: an IdentityFile entry in ~/.ssh/config, or ssh-add after a reboot. If the key is offered and rejected, move to the server.
Read the server's own explanation
The server logs the real reason for every failed attempt. The file depends on the distribution:
tail -50 /var/log/secure # AlmaLinux, Rocky, RHEL, CloudLinux
tail -50 /var/log/auth.log # Debian, Ubuntu
journalctl -u sshd -n 50 # systemd hosts (the unit is named ssh on Debian and Ubuntu)Messages such as Authentication refused: bad ownership or modes for directory or Could not open authorized keys are the server telling you precisely what is wrong. If you can still log in some other way, such as a hosting provider's web console, this is the fastest route. If the server shows nothing at all for your attempt, the connection may never be reaching sshd, so check the firewall and the port.
Permissions and ownership
By default sshd runs with StrictModes yes, which means it refuses keys when the home directory or the .ssh folder is writable by anyone other than the user. This is the single most common server-side cause, especially after a migration or a bulk permissions change on a hosting account:
chmod go-w /home/user
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/authorized_keys
chown -R user:user /home/user/.sshA home directory set to 777 while someone was debugging a web problem will lock out SSH logins without any other visible effect. Fix the mode, not the setting.
SELinux labels on AlmaLinux and RHEL-family systems
On systems with SELinux enforcing, a .ssh directory created by copying files, or restored from a backup, can carry the wrong security label. The permissions look perfect and sshd still cannot read the file. Restoring the default labels fixes it:
restorecon -Rv /home/user/.ssh
ls -Z /home/user/.ssh/authorized_keysIf the audit log shows denials for sshd, this is almost certainly your cause. Do not switch SELinux off to get past it. Relabelling is a one-line fix.
What sshd is actually configured to accept
Effective settings can differ from what you think is in the file, because of Include directives and per-match blocks. Ask sshd for the resolved configuration rather than reading the file:
sshd -T | grep -Ei "pubkeyauthentication|authorizedkeysfile|allowusers|allowgroups|pubkeyacceptedalgorithms|permitrootlogin"Check that pubkeyauthentication is yes, that the authorizedkeysfile path matches where you put the key, and that an AllowUsers or AllowGroups line is not excluding your account. On hosting servers, hardening tools and control panels sometimes add these restrictions without anyone remembering.
Key type and algorithm problems
Old keys fail on new servers. Modern OpenSSH no longer accepts the legacy SHA-1 signature scheme for RSA keys by default, so a very old client talking to a current server can be refused even though the key itself is valid. The sturdy fix is a new key, ideally ed25519, rather than loosening the server:
ssh-keygen -t ed25519 -C "admin@yourcompany"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.example.comIf you must connect from a legacy client during a migration, a temporary override on the client side is better than weakening the whole server, and it should be removed as soon as the key is replaced. Also check that the public key on the server is on one line with no stray line breaks. A key pasted through a chat window or a ticket system often arrives wrapped and silently invalid.
Cloud servers and regenerated keys
On cloud instances, a rebuilt or restored machine may have had its authorised keys reset by the provider's initialisation process, or may belong to a different default user than you expect. Confirm which account the image uses, and whether your key is still attached to the instance in the provider console. This is a frequent cause of "it worked yesterday" after a snapshot restore or a resize.
When you are completely locked out
If no login works at all, you recover through the provider rather than through SSH. Boot the machine into its rescue environment, mount the root filesystem, and repair the home directory permissions or the authorized_keys file directly. We have step-by-step guides for the two providers we are asked about most: OVH rescue mode and the Hetzner rescue system. Take care to put every file back with the correct owner and mode before you reboot, or you will recreate the lockout. If the server will not boot at all, our guide on a Linux server that will not boot after a kernel update is the next stop.
Before you close the ticket
Once you are back in, do two things. Test login from a second session before closing the first, so a bad change cannot lock you out again. And keep a documented break-glass route, such as the provider console, that does not depend on SSH keys working.
If you are locked out of a production server and the clock is running, our emergency server support team can get you back in and put the access back on a sound footing.
Is this problem affecting a live server now?
Bring in a server engineer for urgent diagnosis, recovery and a clearly scoped response to the active incident.
