How to Fix Common SSH Errors

ssh -v [email protected]

The useful lines are near the end: Connecting to (which address and port it tried), Offering public key (which keys it sent), and Authentications that can continue (what the server will accept).

Nothing answered at all. Either the server is off, the address is wrong, or a firewall is silently dropping the connection. Check, in this order:

• The server is running and the IP address matches the one in your dashboard.
• The firewall allows your address on the SSH port: both the dashboard firewall and any firewall inside the server (sudo ufw status). Your own address may have changed if you are on home broadband.
• Your own network allows outgoing SSH. Some office and public Wi-Fi networks block it.

nc -vz 203.0.113.10 22      # "succeeded" means the port is reachable

The server answered, but nothing is listening on that port. Usually it is the wrong port (a storage box uses 23, for example), or the SSH service is not running, often after a config edit with a typo. From the console:

sudo sshd -t                  # prints the config error, if there is one
sudo systemctl status ssh     # "sshd" on AlmaLinux and Rocky
sudo systemctl restart ssh

The server only accepts keys, and none of the keys you offered is allowed for that user. The usual causes:

• Wrong user. The key was added for alice but you are connecting as root, or the other way round.
• Wrong key. Name it explicitly: ssh -i ~/.ssh/id_ed25519 [email protected]. The -v output lists each key it offered.
• Permissions on the server. SSH ignores keys in a folder others can write to. From the console:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
sudo journalctl -u ssh -n 30      # look for "bad ownership or modes"

If the message is Permission denied (publickey,password), the server would accept a password too, so the password was wrong or the user is not allowed to sign in with one. Many servers refuse root passwords on purpose.

SSH remembers each server's key in ~/.ssh/known_hosts and stops if it changes. After you reinstall a server, or when an address you used before now belongs to a new server, this is expected. Check the new fingerprint from the server's console, then remove the old entry:

# on the server's console
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

# on your computer
ssh-keygen -R 203.0.113.10
ssh-keygen -R "[bend.storage.virteche.com]:23"    # for a host on another port

Hosts on a port other than 22 are stored as [host]:port, which is why a plain ssh-keygen -R host sometimes seems to do nothing. If nothing changed on your side, treat the warning as real and check before you connect.

Your SSH agent offered several keys, and the server gave up before reaching the right one. Offer only the key you mean:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 [email protected]

To make it permanent, put it in ~/.ssh/config:

Host myserver
    HostName 203.0.113.10
    User alice
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

SSH refuses a private key that other users can read. On macOS and Linux:

chmod 600 ~/.ssh/id_ed25519

On Windows, in PowerShell:

icacls.exe "$env:USERPROFILE\.ssh\id_ed25519" /inheritance:r
icacls.exe "$env:USERPROFILE\.ssh\id_ed25519" /grant:r "$($env:USERNAME):(R)"

The message ends with Their offer: ssh-rsa: the server only offers an old SHA-1 signature that current SSH clients turn off. The real fix is to update SSH on the server. To get in once and do that:

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa user@old-server

A message like kex_exchange_identification: Connection closed by remote host right after connecting usually means the server is deliberately refusing you, most often because fail2ban banned your address after failed attempts. From the console:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.7

A storage box that has an Allowed IP addresses list signs you in and then closes the connection with a message naming the address it saw, if that address is not on the list. See Connecting to a storage box.

Give each server an entry in ~/.ssh/config with its user, port and key, keep the console in mind before you change SSH or firewall settings, and test changes from a second session while the first stays open. First steps on a new Linux server shows that routine.