ssh: connect to host 203.0.113.10 port 22: Connection refused

This error means your packets reached the server’s IP, and something actively said no — usually because nothing is listening on that port. It’s different from a timeout (Connection timed out), where packets are silently dropped, typically by a firewall. Knowing which one you have narrows the search.

Error Usual causes
Connection refused sshd not running; SSH on a different port; a firewall rule with REJECT
Connection timed out Firewall DROP (server or provider); wrong IP; server down; network issue
No route to host Firewall REJECT with ICMP, network or routing problem
Connection reset by peer / kex_exchange_identification sshd running but refusing: TCP wrappers, MaxStartups, Fail2Ban, overload
Permission denied (publickey) You connected fine — authentication failed → see this guide

Step 1: rule out the basics from your side

ping -c 3 203.0.113.10            # is the server up at all? (ICMP may be blocked)
nc -zv 203.0.113.10 22            # is port 22 reachable?
ssh -v -p 22 [email protected]    # verbose output
  • Double-check the IP — especially after reinstalling or migrating a server.
  • Did you (or your provider) move SSH to another port? Try ssh -p 2222 … with your custom port.
  • Try from a different network (mobile hotspot). Some corporate or public networks block outbound port 22.

Step 2: get a console on the server

If SSH doesn’t work, use your VPS provider’s VNC console in the client area. It connects to the server’s virtual screen and works regardless of SSH and firewall settings. All the next checks run there.

Step 3: is sshd running?

sudo systemctl status ssh       # Debian/Ubuntu ("sshd" on RHEL-family)
sudo systemctl status ssh.socket

If it’s stopped or failed, check why and start it:

sudo journalctl -u ssh -n 50 --no-pager
sudo sshd -t                     # config syntax check
sudo systemctl start ssh

A typo in sshd_config (or a file in sshd_config.d/) stops sshd from starting after a restart — sshd -t points to the line.

Not installed at all (some minimal images)?

sudo apt install openssh-server
sudo systemctl enable --now ssh

Step 4: which port and address is it listening on?

sudo ss -tlnp | grep -E 'sshd|systemd'
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=701,fd=3))
  • A different port → connect with -p, or fix the config.
  • 127.0.0.1:22 only → ListenAddress restricts it to localhost; change or remove it.

Ubuntu 22.10+ socket activation: sshd is started by ssh.socket, and the socket decides the port. If you changed Port in sshd_config, run sudo systemctl daemon-reload && sudo systemctl restart ssh.socket. See changing the SSH port.

Step 5: firewall on the server

sudo ufw status verbose                    # Ubuntu/Debian
sudo firewall-cmd --list-all               # RHEL family
sudo nft list ruleset | grep -n 22
sudo iptables -S | grep -E 'dport 22|INPUT'

Allow SSH again:

sudo ufw allow 22/tcp
sudo firewall-cmd --permanent --add-service=ssh && sudo firewall-cmd --reload

On RHEL-family systems with a custom port, SELinux must also allow it: sudo semanage port -l | grep ssh.

Step 6: banned by Fail2Ban or CrowdSec?

Too many failed attempts (a wrong key, a misconfigured script) can ban your own IP:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.25
sudo cscli decisions list | grep 198.51.100.25
sudo cscli decisions delete --ip 198.51.100.25

Add your static IP to the whitelist (ignoreip in Fail2Ban) to prevent it.

Step 7: hosts.allow / hosts.deny and connection limits

Older setups may use TCP wrappers:

cat /etc/hosts.allow /etc/hosts.deny

And MaxStartups in sshd config limits simultaneous unauthenticated connections — under a brute-force flood, legitimate connections can be dropped (kex_exchange_identification: read: Connection reset by peer). Fail2Ban and a non-standard port help here.

Step 8: provider-level firewall or network

If everything on the server looks right but connections still time out, check any firewall or security group configured in your provider’s panel, and whether the server’s network interface is up (ip -br addr). If the network inside the VPS is misconfigured (after editing Netplan, for example), fix it from the console — see Netplan static IP.

Quick checklist

  1. Refused or timed out?
  2. Right IP and port?
  3. VNC console → systemctl status ssh, sshd -t.
  4. ss -tlnp — listening where?
  5. Firewall rules (and SELinux for custom ports).
  6. Fail2Ban/CrowdSec bans.
  7. Provider firewall, network config.

Once you’re back in, prevent repeats: keep a whitelist for your IP, validate configs before reloading, and keep the console handy. Related: SSH into your VPS.

  • SSH
  • Troubleshooting
  • Linux