SSH Connection Refused on a VPS

What connection refused actually means

Connection refused means the TCP connection was rejected, so either sshd is not running, it listens on another port, or a firewall is rejecting port 22. Check the service, then the port, then the firewall, then fail2ban. A timeout instead of a refusal usually means packets are being dropped silently.

The error is specific. The server answered with a TCP reset, which means the host is reachable and something decided there is no service on that port. Compare it with the two errors people confuse it with.

That distinction saves the most time. Refused is a service or port problem; timeout is a network or provider problem; permission denied is a credential problem.

Check the host and the port first

Confirm the address and the port before changing any configuration. Most refusals after a rebuild or a migration are simply the old IP or an old port in the SSH client.

1. ping -c 4 YOUR.SERVER.IP shows whether the host answers at all. Some providers block ICMP, so a silent ping is not proof of a dead server.
2. nc -vz YOUR.SERVER.IP 22 tests the port directly. A refusal here matches what SSH reports; an open result means the problem is authentication, not the network.
3. ssh -vvv user@YOUR.SERVER.IP prints the negotiation. The last lines name the port it tried and where it stopped.
4. Check the provider panel for the SSH port and IP; some hosts use a non-standard port for managed SSH access.

On Windows, PuTTY shows the same "connection refused" for the same causes. Fill Host Name with the IP, Port with the port from the panel, and check the connection log before changing settings.

Is sshd running and listening?

Two commands answer this: one says whether the service is active, the other says whether it is listening. They are not the same check, and the second is the one that matters.

sudo systemctl status ssh
sudo ss -tlnp | grep -E ':22|:2222'
sudo journalctl -u ssh -n 50 --no-pager

A correct output shows LISTEN on 0.0.0.0:22 or [::]:22 next to sshd. If the service is active but nothing listens, the daemon failed to bind: the port is taken, the config names a different port, or ListenAddress points at an address the server no longer has.

On RHEL, AlmaLinux and Rocky the unit is sshd, not ssh. Start and enable it with sudo systemctl enable --now sshd, then read the journal again if it exits immediately.

The firewall, in three places

A VPS can have three firewalls at once: UFW or firewalld inside the OS, raw iptables or nftables rules, and the provider's security group outside the machine. A port open in one can still be closed in another.

• sudo ufw status verbose shows the OS rules on Ubuntu; sudo ufw allow 22/tcp then sudo ufw reload opens the port.
• sudo iptables -L -n --line-numbers shows raw rules. Look for REJECT or DROP above any ACCEPT for your port; order matters.
• The provider panel has its own firewall or security group. Add an inbound rule for TCP 22, or for the custom port, scoped to your IP.
• Docker can insert its own iptables chains. A container publishing a port may bypass UFW, which is why the rules look right and the port still refuses.

Do not start by flushing every rule. Add the ACCEPT rule you need, confirm the login works, and only then tidy the rest. A blind flush can expose services that were deliberately closed.

Wrong port, fail2ban and sshd_config

Three configuration mistakes produce a refusal even when sshd is healthy: a changed Port, an AllowUsers list that excludes you, and a fail2ban ban on your IP.

1. Open /etc/ssh/sshd_config and read the active Port line; a commented #Port 22 means the default still applies.
2. Run sudo sshd -t to test the file before any restart. A syntax error here is how a working server becomes unreachable.
3. Keep your current session open, then sudo systemctl restart ssh and open a second session to test. If the second session fails, the first one can still undo the change.
4. From the console, run sudo fail2ban-client status sshd and, if your IP is listed, sudo fail2ban-client set sshd unbanip YOUR.IP.
5. Whitelist your office or admin IP in /etc/fail2ban/jail.local under ignoreip so a typo cannot lock you out again.

If the panel shows a custom SSH port, the client needs ssh -p PORT user@IP, and the firewall needs that port, not 22.

Recovery when SSH is already down

When no login works, stop editing blind. Use the provider's VNC console, serial console or rescue mode, which reaches the machine without SSH.

1. Open the console from the VPS panel and log in as root with the password from the provider.
2. Read the journal: journalctl -u ssh -n 100 --no-pager usually names the exact line that broke.
3. Fix sshd_config, run sshd -t, then restart the service.
4. In rescue mode, mount the disk read-write, edit the file from the mounted root, unmount, then boot normally.
5. Test the port from outside with nc -vz IP 22 before closing the console.

Take a snapshot before rescue-mode surgery if the panel offers one. The sudo user guide covers creating a second admin account, which is the cheapest insurance against a lockout.

Prevent the next lockout

Most lockouts are self-inflicted during a hardening change. Four habits remove almost all of them.

• Keep a second admin user with sudo and a tested key, so one broken account is not fatal.
• Allow both the old and the new SSH port for a week when you change it, then close the old one.
• Whitelist your admin IP in fail2ban and in the provider firewall before you tighten anything.
• Monitor the port from outside with an uptime check, so a closed port is an alert, not a surprise at 2 a.m.

If the server is a WebJi VPS, the panel console and rescue options are part of the service. Support at support@webji.services can read the journal with you; email is answered 24/7 in Hindi and English, with an average first reply under 60 minutes. For host-level firewall policy, the CSF firewall guide covers the cPanel side.