TroubleshootingWritten by GLWS14 min readUbuntu 24.04 LTS / AlmaLinux 9
Commands run on your server unless a section says otherwise. Replace example usernames, addresses and paths with your own values. Keep a working session open when changing remote access.

Read the exact message

"Permission denied" means the server was reached and refused your login, so networking and firewall are fine. The text in brackets tells you which methods were tried. "Permission denied (publickey)" means key login was the only option and your key was not accepted. "(publickey,password)" means the password also failed or is not accepted. "Too many authentication failures" means your agent offered too many keys. A timeout or "connection refused" is a different problem, covered in the firewall and lockout guides.

Get the verbose output

Run SSH with -vvv and read what happens: which user name is used, which key files are tried, whether the server accepts a key and which methods it offers. Ignore the noise and look for the lines "Offering public key", "Server accepts key" or "Authentications that can continue".

On your computer
ssh -vvv deploy@YOUR_SERVER 2>&1 | grep -i -E "offering|accepts|authentications that can continue|permission denied|identity file|no such identity"

Check the user name

The most common cause is the wrong account name. Cloud images use different default users: ubuntu on Ubuntu images, debian on Debian, almalinux on AlmaLinux, root on some, or the name you created during setup. The control panel or order details show which. Root login may also be disabled, as the hardening guide recommends.

On your computer
ssh ubuntu@YOUR_SERVER
ssh almalinux@YOUR_SERVER
ssh deploy@YOUR_SERVER

Check which key is offered

SSH offers keys from your agent and from default files. If it offers the wrong ones, or too many, tell it exactly which to use and to use only that. Check that the key you added to the server is the same one: compare fingerprints.

On your computer
ssh-add -l
ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes deploy@YOUR_SERVER
~/.ssh/config entry so you never think about it again
Host myserver
    HostName YOUR_SERVER
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Check key file permissions on your computer

SSH refuses private keys that other users can read ("UNPROTECTED PRIVATE KEY FILE"). Make the key readable only by you. On Windows, remove other users from the file's permissions or use the OpenSSH folder in your profile.

Linux and macOS
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
ls -l ~/.ssh/

Check permissions on the server

The SSH server also ignores keys when the folders involved are writable by others. Your home directory must not be group- or world-writable, ~/.ssh should be 700 and authorized_keys 600, all owned by you. Use the recovery console or another working login to inspect them. The server's authentication log states "bad ownership or modes" when this is the problem.

On the server, as the affected user
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys
chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
wc -l ~/.ssh/authorized_keys
cat ~/.ssh/authorized_keys | cut -c1-80
AlmaLinux: restore SELinux labels
restorecon -Rv ~/.ssh
Each key must be on a single line starting with ssh-ed25519, ssh-rsa or similar. Line breaks pasted into the file break it.

Check the server log

The server states exactly why it refused you. Watch the log while you try to connect from another terminal. Messages such as "Invalid user", "Authentication refused: bad ownership or modes", "User not allowed because account is locked" and "key type not in PubkeyAcceptedAlgorithms" each point to a different fix.

Ubuntu
sudo journalctl -u ssh -f
AlmaLinux
sudo journalctl -u sshd -f
Both systems: recent failures
sudo journalctl -u ssh -u sshd --since "30 minutes ago" --no-pager | grep -i -E "invalid|refused|failed|not allowed|error" | tail -n 20

Check server settings

See the effective configuration. If password login is off and you have no working key, you will see exactly this error. If AllowUsers or AllowGroups exists, your account must be listed. Also check that the account is not locked or expired. Config changes need a test and a reload, as in the hardening guide.

On the server (use the console if you are locked out)
sudo sshd -T | grep -i -E "passwordauthentication|pubkeyauthentication|permitrootlogin|allowusers|allowgroups|authorizedkeysfile"
sudo passwd -S deploy
sudo chage -l deploy | head -n 5

Old key types and algorithms

Newer OpenSSH versions refuse the old ssh-rsa signature algorithm that uses SHA-1. An old RSA key may stop working on a new server. The fix is to create an Ed25519 key and add it. Allowing the old algorithm is only a temporary workaround, and not one to leave in place.

On your computer
ssh-keygen -t ed25519 -C "my laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@YOUR_SERVER

Fix "Too many authentication failures"

The server allows only a few attempts per connection (MaxAuthTries, usually 6), and an agent holding many keys can use them all before the right one is tried. Tell SSH to offer only the key you name, as in the config example above.

On your computer
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 deploy@YOUR_SERVER

If you are locked out completely

Use the control panel console to log in locally and fix the account, keys or configuration, as the lockout recovery guide describes. After you are back in, test a fresh connection from a second terminal before closing the console, and keep a second working key as a spare.

Official documentation

These upstream references provide more detail on the commands and workflows in this guide.

KEEP LEARNING

Related GLWS guides

Browse all guides