Can’t connect via SSH

If SSH to your mHost VPS won't connect, the cause is almost always one of a handful: the server is off, the address or port is wrong, a firewall is blocking the connection, the sshd service isn't responding, your IP is banned in fail2ban, or the password or key doesn't match. This article is a checklist for reading what the error message means and fixing it — using the VMmanager 6 graphical console when SSH itself is unreachable.

What you'll need

• An mHost VPS running Ubuntu 22.04/24.04, Debian 11/12, or AlmaLinux/Rocky Linux 8/9.
• The server's IP address and credentials — root or a sudo user, a password or an SSH key.
• Access to the VMmanager 6 panel — as a fallback: its VNC console works independently of SSH and the server's firewall, so it lets you fix the problem from inside even when SSH itself is unreachable. If you haven't logged in to the panel yet, see "How to log in to VMmanager 6".

Step 1. Read what the error actually says

An SSH client usually doesn't just fail silently — it names the reason, and that immediately narrows things down:

• `Connection refused` (the full line usually reads ssh: connect to host 185.246.66.12 port 22: Connection refused) — the server answered "nobody's listening here": the packet got through, but the connection was rejected outright. Usually that means sshd isn't running or is listening on a different port (Step 5); less often, your IP was just banned by fail2ban (Step 6 — fail2ban's default ban action actively rejects rather than staying silent) or an explicit firewall rule is rejecting the connection. Either way, the network and the IP address are fine — the server did answer you.
• `Connection timed out` (ssh: connect to host 185.246.66.12 port 22: Connection timed out), or the connection just hangs with no response at all — unlike "refused," nothing came back here whatsoever. Usually a firewall is silently dropping the packets — for example, ufw's default policy (Step 4) — or the server is off (Step 2), or you've got the wrong IP address (Step 3).
• `Permission denied (publickey,password)` (or (publickey) if the password is disabled) — the network, the firewall, and sshd are no longer the issue: the connection is already established, sshd is answering, it just didn't accept your credentials. That's a login, password, or key problem (Step 7).

Step 2. Make sure the server is actually powered on

1. Log in to the VMmanager 6 panel — see "How to log in to VMmanager 6".
2. Find your server in the VM list and check its status.
3. If the server is off, open the "⋮" menu next to it and choose "Start."
4. If it's listed as running but isn't responding to anything at all, the same menu also has "Restart."

📷 screenshot: VM list showing the server status and the "⋮" menu with "Start"/"Restart"

The most reliable check is to open the graphical VNC console right in the browser — it has no separate network or firewall requirements of its own, so if the server has booted, you'll see its screen regardless. For the full walkthrough, see "VNC console and first connection (SSH/RDP)".

Step 3. Check the IP address, port, and username

• IP address. Get it from the server activation email or the "IP addresses" tab on the VM's page in VMmanager 6. It usually stays the same after an OS reinstall, but it's worth double-checking — especially if you're connecting from an old note or a saved profile in your SSH client.
• Port. SSH listens on 22 by default, and without a -p flag the client always tries that one. If the port was changed (see "Hardening SSH"), specify it explicitly: ssh -p 2222 root@185.246.66.12.
• Username. root works on a fresh server. If you later created a separate sudo user and restricted root over SSH, connect as that user instead: ssh user@185.246.66.12, not root. Usernames are case-sensitive.

Step 4. Check whether a firewall is blocking the connection

If the error in Step 1 was a timed out, start here — packets are most likely being silently dropped by a firewall.

Ubuntu / Debian (ufw)

sudo ufw status

If there's no allow rule for SSH in the list, add one:

sudo ufw allow OpenSSH

AlmaLinux / Rocky (firewalld)

sudo firewall-cmd --state
sudo firewall-cmd --list-services

If ssh isn't among the allowed services, add it:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

If you changed the SSH port, open it separately — --add-service=ssh won't cover that:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

If the firewall's status is inactive (ufw) or not running (firewalld), it isn't the cause — move on to the next step. For a full walkthrough of ufw's rules and logic, see "Setting up the UFW firewall".

Step 5. Make sure the sshd service is actually running

If the firewall checks out and the error in Step 1 was refused, the service itself is the likely culprit. You can only check and fix this from inside the server — through the VNC console (Step 2), since SSH is exactly what you can't use to get there.

Check its status:

# Ubuntu/Debian
systemctl status ssh

# AlmaLinux/Rocky Linux
systemctl status sshd

If the status isn't active (running), start it and enable it on boot:

# Ubuntu/Debian
systemctl enable --now ssh

# AlmaLinux/Rocky Linux
systemctl enable --now sshd

Check which port it's actually listening on:

ss -tlnp | grep ssh

The port after the colon in the output (for example, 0.0.0.0:22) should match whatever you pass to ssh -p.

If the service crashes right after starting, check its log:

# Ubuntu/Debian
journalctl -u ssh -n 50 --no-pager

# AlmaLinux/Rocky Linux
journalctl -u sshd -n 50 --no-pager

A syntax error in /etc/ssh/sshd_config left over from a manual edit is a common cause of crashes; you can check the configuration without restarting using sudo sshd -t (also used in the "Hardening SSH" article).

Step 6. Check whether your IP is banned in fail2ban

If there were several failed login attempts in a row recently — you mistyped the password yourself, say, or other devices share your IP address through NAT — fail2ban may have banned it automatically.

You can get onto the server to check this through the VNC console (Step 2) — it doesn't go through the server's network stack or firewall, so a fail2ban ban has no effect on it. Or connect over SSH from a different IP address (mobile data, another network) if you have one available.

Check the sshd jail's status:

sudo fail2ban-client status sshd

If your IP shows up in Banned IP list, lift the ban (replace 203.0.113.10 with your own address):

sudo fail2ban-client set sshd unbanip 203.0.113.10

Step 7. Sort out authentication: key or password

If the connection made it this far, the network, the firewall, and sshd itself are no longer the issue — only your credentials are left:

• `Permission denied (publickey,password)` — the server accepts both a key and a password, but neither one you supplied worked.
• `Permission denied (publickey)` — the server only accepts a key (the password is disabled — PasswordAuthentication no); without the right key, no number of password attempts will get you in.

Password. Make sure you're entering the password for the account on the server (root or your sudo user), not the password for the VMmanager 6 panel or the my.mhost.ee client area — those are different passwords. Forgot the root password? Change it in VMmanager 6: the server's page → "⋮" → "Change password."

The wrong key. If you have several SSH keys on your computer, the client might offer the wrong one. Specify it explicitly:

ssh -i ~/.ssh/id_ed25519 root@185.246.66.12

The key isn't on the server. Through the VNC console (Step 2), check that the public key is actually recorded on the server:

cat ~/.ssh/authorized_keys

Compare it line by line with the key on your own computer (cat ~/.ssh/id_ed25519.pub). If the line isn't there, add it (see step 2 of the "Hardening SSH" article — it covers both ssh-copy-id and doing it by hand).

File permissions. SSH is picky about file permissions, on both the server and the client: ~/.ssh needs to be 700, authorized_keys needs to be 600 on the server, and your private key needs to be 600 on your own computer too. Permissions that are too open are a common cause of a silent rejection specifically with a key:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Password disabled on the server. If you don't have a working key and the server answers Permission denied (publickey) with no password in the list, password login is disabled on it (PasswordAuthentication no, see the "Hardening SSH" article) and won't work no matter how many times you try. Temporarily turn it back on through the VNC console (Step 2):

sudo nano /etc/ssh/sshd_config

Find the line PasswordAuthentication no and change it to PasswordAuthentication yes, save the file, and restart the service (commands are in Step 5 of this article). Then log in with the password and set up the key properly.

What's next

Once access is back, it's worth cutting the odds of a repeat: set up key-based login and turn off passwords — see "Hardening SSH"; make sure the port is protected by a firewall, if it isn't already — "Setting up the UFW firewall"; and add automatic banning for repeated failed logins — "Fail2ban: protection against brute-force". For the rest of the basic security settings, see the "Basic VPS security checklist" article.