SSH is the primary way to manage your server, so being unable to connect can halt your workflow. This guide covers the most common SSH connection errors, their causes, and step-by-step fixes for each scenario.

Whether you are seeing "Connection refused," "Connection timed out," "Permission denied," or another error, you will find the solution here.

Before You Start

Before diving into specific error messages, run through these quick checks:

Error: "Connection Refused"

ssh: connect to host 203.0.113.10 port 22: Connection refused

What It Means

The server received your connection request but actively rejected it. This typically means the SSH daemon (sshd) is not running or is listening on a different port.

How to Fix It

Option 1 — Restart SSH via the web console:

# Check status
systemctl status sshd
Restart the service
systemctl restart sshd
Ensure it starts on boot
systemctl enable sshd

Option 2 — Check if SSH is listening on a different port:

# Via web console
ss -tlnp | grep ssh

If SSH is listening on a non-standard port (e.g., 2222), connect using:

ssh -p 2222 [email protected]

Option 3 — Reinstall the SSH server:

If sshd is not installed or is corrupted:

# Ubuntu / Debian
apt update && apt install --reinstall openssh-server -y
systemctl start sshd
systemctl enable sshd
AlmaLinux / Rocky / CentOS
dnf reinstall openssh-server -y
systemctl start sshd
systemctl enable sshd

Error: "Connection Timed Out"

ssh: connect to host 203.0.113.10 port 22: Connection timed out

What It Means

Your SSH client sent a connection request but received no response. The request either never reached the server or was silently dropped. This is different from "Connection refused" — with a timeout, there is no response at all.

How to Fix It

Check 1 — Is the server reachable?

ping 203.0.113.10

If ping also times out, the issue is likely network-related or the server is completely down. Use the web console in your dashboard to check.

Check 2 — Firewall blocking port 22.

A firewall on the server may be dropping SSH packets. Via the web console:

# Check iptables
iptables -L -n | grep 22
Check ufw (Ubuntu)
ufw status
Check firewalld (CentOS/AlmaLinux)
firewall-cmd --list-ports

If port 22 is not allowed, add a rule:

# ufw (Ubuntu)
ufw allow 22/tcp
firewalld (CentOS/AlmaLinux)
firewall-cmd --permanent --add-port=22/tcp
firewall-cmd --reload
iptables
iptables -I INPUT -p tcp --dport 22 -j ACCEPT

Check 3 — Data Mammoth Cloud Firewall.

If you are using the Data Mammoth Cloud Firewall feature, verify that port 22 is allowed in your firewall policy. Check under Services > [Your Server] > Firewall in the dashboard.

Check 4 — ISP or local network blocking.

Some corporate networks, public Wi-Fi, and ISPs block outbound connections on port 22. Try:

• Connecting from a different network (e.g., mobile hotspot)
• Using a VPN
• If your SSH is on a non-standard port, try port 443, which is rarely blocked

Error: "Permission Denied (publickey)"

Permission denied (publickey).

What It Means

The server requires SSH key authentication, and either you do not have the correct key or your key is not being offered by your SSH client.

How to Fix It

Check 1 — Verify you have the right key:

# List your SSH keys
ls -la ~/.ssh/
Try specifying the key explicitly
ssh -i ~/.ssh/id_ed25519 [email protected]

Check 2 — Check key permissions:

SSH is strict about file permissions. Fix them:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Check 3 — Enable password authentication temporarily.

If you have access via the web console, temporarily enable password authentication:

# Edit the SSH configuration
nano /etc/ssh/sshd_config

Find these lines and set them as shown:

PasswordAuthentication yes
PubkeyAuthentication yes

Save the file and restart SSH:

systemctl restart sshd

Now try connecting with a password. Once logged in, fix your SSH key configuration.

Check 4 — Ensure your public key is in authorized_keys:

On the server (via web console), verify:

cat ~/.ssh/authorized_keys

If your public key is not listed, add it:

echo "your-public-key-content" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Error: "Permission Denied (password)"

[email protected]: Permission denied, please try again.

What It Means

You are entering an incorrect password, or the root account does not allow password-based login.

How to Fix It

• Verify the password. Copy it directly from your Data Mammoth dashboard or the provisioning email. Passwords are case-sensitive and may contain special characters.
• Reset the password. If you have forgotten the password, some plans allow you to reset the root password from the dashboard under Services > [Your Server] > Settings.
• Use the web console. Log in through the web console and change the password:

passwd root

• Check SSH configuration. Ensure password authentication is enabled:

grep PasswordAuthentication /etc/ssh/sshd_config

If it shows PasswordAuthentication no, change it to yes and restart SSH.

Error: "Host Key Verification Failed"

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
...
Host key verification failed.

What It Means

Your SSH client has previously connected to this IP address and saved the server's fingerprint. The current fingerprint does not match the saved one. This happens when:

• You reinstalled the operating system on the server
• The server was reprovisioned
• A different server was assigned the same IP address

How to Fix It

If you know the change is legitimate (e.g., you just reinstalled the OS), remove the old fingerprint:

ssh-keygen -R 203.0.113.10

Then try connecting again. You will be prompted to accept the new host key.

Warning: If you did NOT make any changes to the server and see this message, it could indicate a security issue (man-in-the-middle attack). Contact support before proceeding.

Error: "No Route to Host"

ssh: connect to host 203.0.113.10 port 22: No route to host

What It Means

There is a networking issue preventing your computer from reaching the server. This is usually an infrastructure-level problem.

How to Fix It

• Wait a few minutes and try again — the issue may be a temporary routing problem.
• Try from a different network.
• Check the Data Mammoth status page for any network incidents.
• If the issue persists, open a support ticket with the error message and your location.

General SSH Troubleshooting Checklist

Use this checklist to systematically diagnose any SSH connection issue:

• [ ] Server status is Active in the dashboard
• [ ] IP address is correct (copied from dashboard)
• [ ] SSH port is correct (default: 22)
• [ ] Server responds to ping
• [ ] Firewall allows port 22 (or your custom SSH port)
• [ ] SSH service (sshd) is running on the server
• [ ] Credentials are correct (username and password or SSH key)
• [ ] File permissions on SSH keys are correct (600 for private key)
• [ ] Web console access works (to rule out server-level issues)
• [ ] Trying from a different network (to rule out local network issues)

What to Do Next

• How to Connect to Your Server via SSH — Complete SSH connection guide for all platforms.
• Server Not Responding — Troubleshooting Guide — Broader troubleshooting for unresponsive servers.
• High CPU Usage — Diagnosis & Fix — If the server is reachable but slow.

Need Help?

If you have tried the steps above and still cannot connect, open a support ticket from your Data Mammoth dashboard. Include:

• Your server's IP address
• The exact error message
• Your operating system (Windows, macOS, Linux)
• The SSH client you are using
• Whether you can access the server via the web console