A full SSH error usually looks like this:

Permission denied (publickey).
Permission denied (publickey,password).
Permission denied, please try again.

These mean different things.

If you only copy the last line Permission denied and search it, you'll easily go off track. Paste the full error first, especially the authentication methods in parentheses.

I suggest adding -v first to see detailed logs:

ssh -v root@your_server_ip

If there's too much information, use the more verbose one:

ssh -vvv root@your_server_ip

Focus on these lines:

Offering public key: /Users/you/.ssh/id_ed25519
Authentications that can continue: publickey
No more authentication methods to try.

This shows the client did take the key and try it, but the server didn't accept it.

Not every system uses root for VPS login.

Common default users are roughly:

I once helped a friend look at this. He kept using:

ssh [email protected]

But that machine was an Ubuntu cloud image, which by default only allows:

ssh [email protected]

Password, key, and port were all fine; it was simply the wrong username.

When troubleshooting, do three things first:

1. Check the VPS activation email
2. Check the login instructions in the cloud console
3. Check whether you specified an SSH user when creating the instance

If you're not sure, try these first:

ssh root@your_server_ip
ssh ubuntu@your_server_ip
ssh debian@your_server_ip

Don't reset the system right away.

Many people have several SSH keys locally:

ls -la ~/.ssh

You might see:

id_rsa
id_rsa.pub
id_ed25519
id_ed25519.pub
my-vps.pem
company-key.pem

The SSH client doesn't necessarily automatically pick the one you want. The most reliable approach is to specify it explicitly:

ssh -i ~/.ssh/my-vps.pem root@your_server_ip

If you already wrote ~/.ssh/config, also check whether the Host match is wrong:

Host my-vps
  HostName your_server_ip
  User root
  IdentityFile ~/.ssh/my-vps.pem
  IdentitiesOnly yes

Then log in:

ssh my-vps

IdentitiesOnly yes is very useful here. It makes the client use only the key you specify, avoiding the local agent stuffing in a bunch of unrelated keys and the server rejecting early.

If you see a prompt like:

WARNING: UNPROTECTED PRIVATE KEY FILE!
Permissions 0644 for 'my-vps.pem' are too open.
This private key will be ignored.

That's not the server rejecting you; it's your local SSH client not using this private key at all.

Fix the permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/my-vps.pem

If it's a public key file:

chmod 644 ~/.ssh/my-vps.pem.pub

Try again:

ssh -i ~/.ssh/my-vps.pem root@your_server_ip

Windows users on WSL also need to change permissions inside WSL. When the private key is on a Windows mounted drive, the permission model can be annoying, so it's best to copy it directly into the WSL ~/.ssh/ directory.

If you can still get in via console VNC, rescue mode, or the cloud vendor's Web Shell, check server-side permissions:

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

For root, it should usually be:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
chown -R root:root /root/.ssh

For a regular user, say ubuntu:

chmod 700 /home/ubuntu/.ssh
chmod 600 /home/ubuntu/.ssh/authorized_keys
chown -R ubuntu:ubuntu /home/ubuntu/.ssh

An easily overlooked pitfall: you used root to write the key into a regular user's directory, so the owner is still root.

For example:

-rw------- 1 root root 399 authorized_keys

But you're logging in as ubuntu, so that's wrong. Change it to:

chown ubuntu:ubuntu /home/ubuntu/.ssh/authorized_keys

authorized_keys should contain the public key, not the private key.

A public key usually looks like:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... yourname@machine

Or:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... yourname@machine

A private key usually looks like this, never put it in:

-----BEGIN OPENSSH PRIVATE KEY-----
...
-----END OPENSSH PRIVATE KEY-----

If you have the private key locally, you can generate the corresponding public key like this:

ssh-keygen -y -f ~/.ssh/my-vps.pem

Then append the output to the corresponding user's on the server:

~/.ssh/authorized_keys

When appending, use:

echo 'ssh-ed25519 AAAA...' >> ~/.ssh/authorized_keys

Don't overwrite the original file unless you're sure there are no other keys still in use.

If you've changed SSH security settings, focus on:

sudo sshd -t
sudo grep -E '^(PasswordAuthentication|PubkeyAuthentication|PermitRootLogin|AuthorizedKeysFile|AllowUsers|DenyUsers)' /etc/ssh/sshd_config

There are a few common problems.

PasswordAuthentication no

PasswordAuthentication yes

sudo sshd -t

sudo systemctl reload ssh

sudo systemctl reload sshd

PermitRootLogin no

PermitRootLogin prohibit-password

AllowUsers deploy

If you can get into the console, look at the SSH logs directly.

Ubuntu / Debian common:

sudo tail -n 100 /var/log/auth.log

Rocky / AlmaLinux / CentOS common:

sudo tail -n 100 /var/log/secure

systemd also works:

sudo journalctl -u ssh -n 100 --no-pager
sudo journalctl -u sshd -n 100 --no-pager

You'll see a clearer reason, such as:

Failed publickey for root from 1.2.3.4 port 52110 ssh2
Authentication refused: bad ownership or modes for directory /root/.ssh
User ubuntu not allowed because not listed in AllowUsers
Failed password for invalid user admin from 1.2.3.4

This is far more effective than blind guessing locally.

If you've entered the wrong thing many times in a row, it may not be an authentication config problem but your IP being blocked.

Check Fail2Ban first:

sudo fail2ban-client status
sudo fail2ban-client status sshd

If your IP is in the ban list:

sudo fail2ban-client set sshd unbanip your_home_ip

If you can't get in at all, you can only handle it from the cloud console, VNC, or rescue mode.

Also check the cloud vendor firewall:

• Whether the security group allows port 22
• Whether only a certain IP is allowed to log in
• Whether your home broadband IP has changed
• Whether you changed the SSH port to something like 2222 or 22022

If the port was changed, the command needs -p:

ssh -p 2222 -i ~/.ssh/my-vps.pem root@your_server_ip

Mind the case: in the SSH command the port flag is lowercase -p, while in scp the port is uppercase -P.

If SSH is completely unable to log in, don't rush to reinstall. Follow this order:

mkdir /mnt/sysroot
mount /dev/vda1 /mnt/sysroot

lsblk

cat /mnt/sysroot/etc/ssh/sshd_config
ls -la /mnt/sysroot/root/.ssh

If it's only:

• Wrong username
• Wrong key permissions
• Wrong authorized_keys
• Wrong sshd config

Just fix it; no reinstall needed.

But if you see these signals, be careful:

• Unknown public keys appear in authorized_keys
• Unknown users were added
• Lots of successful login records in the SSH logs
• /etc/sudoers was modified
• Unknown tasks in crontab / systemd
• The machine is suspected of being used for port scanning, packet sending, or mining

This is no longer just an SSH login problem; treat it as an intrusion incident. You can read this: 24-hour response checklist after a VPS is compromised.

After fixing, I suggest organizing it into this state:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password

Then set up a regular sudo user:

adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Write locally in ~/.ssh/config:

Host my-vps
  HostName your_server_ip
  User deploy
  Port 22
  IdentityFile ~/.ssh/my-vps.pem
  IdentitiesOnly yes

From then on, logging in is one line:

ssh my-vps

Don't type a long string by hand every time, and don't leave root password login enabled long-term.

When you hit Permission denied, go in this order:

1. ssh -v user@ip to see the full authentication process
2. Confirm whether the username is root, ubuntu, debian, or the vendor-specified user
3. Use ssh -i key user@ip to explicitly specify the private key
4. Fix local private key permissions: chmod 600 key
5. Check server-side .ssh and authorized_keys permissions
6. Confirm authorized_keys contains the public key, not the private key
7. Check PasswordAuthentication, PermitRootLogin, AllowUsers
8. Look at /var/log/auth.log, /var/log/secure, or journalctl
9. Check whether Fail2Ban has banned your IP
10. Check the cloud firewall, security group, and SSH port
11. If still unable to get in, use VNC / rescue mode to fix the config

If your symptom isn't Permission denied but connection timeout, port unreachable, or service not responding, the troubleshooting direction is different. You can continue with: VPS service started but inaccessible from the internet and What to do when a VPS is wrongly banned by Fail2Ban.

Finally, a practical tip: before changing SSH config, open two terminals first. Keep one existing SSH session open without disconnecting, and use the other to test a new connection. Once you confirm the new connection works, close the old window. This small habit can save you from rescuing the machine many times.