SSH Connection Refused: What It Means and How to Fix It

When you try to connect to a server over SSH and get “Connection refused,” it means your machine reached the server, the server responded, and the server said no. The TCP connection was actively rejected. Something on the server side is not accepting SSH connections on the port you tried.

ssh: connect to host example.com port 22: Connection refused

This is different from a timeout. A timeout means no response at all – your packets went out and nothing came back. Connection refused means the server is reachable and responsive, but nothing is listening on port 22 (or whatever port you tried). The distinction matters because the causes and fixes are completely different.

Connection refused vs connection timed out#

These two errors look similar but point to different problems. Knowing which one you are dealing with narrows the diagnosis immediately.

Connection refused

ssh: connect to host example.com port 22: Connection refused

The server received your connection attempt and sent back a TCP RST (reset) packet. This means:

• The server is online and reachable on the network
• The server’s network stack is functioning
• Nothing is listening on the port you connected to

The server is telling you explicitly: “I heard you, but there is nothing here for you on this port.”

Connection timed out

ssh: connect to host example.com port 22: Connection timed out

Your machine sent a connection request and got no response at all. This means one of:

• A firewall between you and the server is silently dropping packets
• The server is offline or unreachable
• The hostname resolved to the wrong IP address
• Network routing between you and the server is broken

A timeout gives you less information because the silence could come from anywhere between your machine and the destination. A refusal at least confirms the server itself is alive.

No route to host

ssh: connect to host example.com port 22: No route to host

Your machine cannot find a network path to the destination. This is a routing or network configuration issue, not an SSH issue. The server may be on a private network you cannot reach, the IP may not exist, or there is a network infrastructure problem between you and the destination.

Causes and fixes#

SSH service is not running

The most common cause on a server you manage yourself. The SSH daemon (sshd) is not running, so nothing is listening on port 22.

How to check (requires console access, not SSH):

sudo systemctl status sshd

If the service is inactive or failed:

sudo systemctl start sshd
sudo systemctl enable sshd

The enable command ensures sshd starts automatically on boot. Without it, the service stops again after the next reboot.

On Ubuntu/Debian, the service is sometimes called ssh instead of sshd :

sudo systemctl status ssh
sudo systemctl start ssh

If SSH is not installed (common on fresh Ubuntu installations):

sudo apt update && sudo apt install openssh-server

On CentOS/RHEL, OpenSSH server is typically installed by default but may need to be enabled:

sudo dnf install openssh-server
sudo systemctl start sshd
sudo systemctl enable sshd

Wrong port

SSH defaults to port 22, but the server may be configured to use a different port. If you connect on 22 and SSH is running on 2222, you get connection refused on 22.

Try connecting on a different port:

ssh -p 2222 user@example.com

If you have console access, check the configured port:

grep -i "^Port" /etc/ssh/sshd_config

If this returns nothing, SSH is using the default (port 22). If it returns a different port number, that is where SSH is listening.

For more on SSH ports and how to configure them, see What port does SSH use.

Firewall blocking the port

A firewall on the server is blocking inbound connections on port 22. The SSH service is running, but the firewall drops or rejects the connection before it reaches sshd.

Check UFW (Ubuntu/Debian):

sudo ufw status

If port 22 is not in the allowed list:

sudo ufw allow 22/tcp

Check firewalld (CentOS/RHEL):

sudo firewall-cmd --list-all

If SSH is not listed under services or ports:

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

Check iptables directly:

sudo iptables -L -n | grep 22

Look for a DROP or REJECT rule targeting port 22.

Cloud provider security groups are a separate layer. AWS, GCP, and Azure all have their own firewall rules that sit in front of the server’s OS-level firewall. If you have just provisioned a new instance, check that the security group allows inbound TCP on port 22 from your IP. This is the number one reason SSH fails on new cloud instances.

IP address banned

If you (or someone on your IP) made too many failed login attempts, the server may have banned your IP address. Tools like fail2ban and DenyHosts automatically block IPs that show brute force behavior.

Check if your IP is banned by fail2ban:

sudo fail2ban-client status sshd

This shows the list of currently banned IPs. If your IP is in the list:

sudo fail2ban-client set sshd unbanip YOUR.IP.ADDRESS

Check /etc/hosts.deny (used by DenyHosts and TCP wrappers):

grep YOUR.IP.ADDRESS /etc/hosts.deny

If your IP appears, remove the line and restart the service.

Check iptables for your IP:

sudo iptables -L -n | grep YOUR.IP.ADDRESS

IP banning is a legitimate security measure. Automated bots constantly probe SSH ports with common username/password combinations – the same kind of credential stuffing that targets WordPress login pages. If your IP was banned because of too many failed password attempts, consider switching to SSH key authentication to avoid this in the future. Keys do not fail authentication the way passwords do, so they do not trigger ban thresholds.

On Hostney, SSH brute force attempts are handled by the server-level bot detection system, which identifies and blocks malicious IPs before they can accumulate enough failed attempts to be a problem. If you are locked out, contact support to check if your IP was caught by an automated rule.

SSH is listening on a specific interface only

The SSH daemon can be configured to listen only on specific network interfaces. If sshd is bound to 127.0.0.1 (localhost), it only accepts connections from the machine itself. Remote connections are refused even though the service is running.

Check the bind address:

grep -i "^ListenAddress" /etc/ssh/sshd_config

If this returns ListenAddress 127.0.0.1 or a specific internal IP, that is why remote connections are refused. To accept connections on all interfaces:

ListenAddress 0.0.0.0

Or remove the ListenAddress directive entirely (the default is to listen on all interfaces). Restart sshd after changing the configuration:

sudo systemctl restart sshd

MaxStartups limit reached

The SSH daemon has a configuration directive called MaxStartups that limits the number of concurrent unauthenticated connections. If too many connections are in the authentication phase at the same time, new connections are refused.

This typically happens when:

• A bot is hammering the SSH port with rapid connection attempts
• An automated script is opening many SSH connections simultaneously
• Someone is running a parallel SCP/SFTP transfer tool that opens too many connections at once

The default is usually MaxStartups 10:30:100 , which means: accept the first 10 connections, then start randomly dropping connections with an increasing probability, and hard-refuse anything beyond 100.

If this is affecting legitimate use:

grep MaxStartups /etc/ssh/sshd_config

Increasing the value helps if the problem is legitimate concurrent connections, but if the problem is a bot attack, increasing it just gives the bots more room. Address the source of the connections first.

Server has been rebuilt or IP changed

If the server was recently rebuilt, migrated, or assigned a new IP, the hostname might resolve to a different machine that does not have SSH configured. Or the new server has a different SSH configuration than the old one.

Verify the IP you are connecting to:

nslookup example.com

or

dig example.com +short

Compare this to the IP you expect. If the DNS points to the wrong IP, you are connecting to the wrong machine entirely.

Diagnosing from the client side#

When you cannot SSH into the server, you can still gather useful information from the client side.

Test port reachability

nc -zv example.com 22

Connection refused output:

example.com [93.184.216.34] 22 (ssh): Connection refused

Confirms the server is reachable but nothing is on port 22.

Success output:

example.com [93.184.216.34] 22 (ssh) open

Port 22 is open and something is listening. If SSH still fails, the problem is in the authentication phase, not the connection phase.

Timeout (no output, hangs): a firewall is dropping packets somewhere.

Use verbose SSH output

ssh -vvv user@example.com

The triple -v gives maximum verbosity. The output shows every step of the connection process: DNS resolution, TCP connection, SSH protocol negotiation, key exchange, and authentication. The point where it fails tells you what is wrong.

For connection refused, the verbose output stops at the TCP connection phase:

debug1: Connecting to example.com [93.184.216.34] port 22.
debug1: connect to address 93.184.216.34 port 22: Connection refused

This confirms the problem is at the network/service level, not authentication.

Check if the server responds on other ports

If SSH is refused on port 22, check if the server is reachable at all:

nc -zv example.com 80
nc -zv example.com 443

If port 80 or 443 responds but port 22 does not, the server is online but SSH specifically is either not running or blocked. If nothing responds, the server may be completely down or unreachable from your network.

Scan for SSH on common ports

If you suspect SSH was moved to a non-standard port:

nc -zv example.com 2222
nc -zv example.com 2200
nc -zv example.com 22000

Or if you have nmap available:

nmap -p 22,2222,2200,22000 example.com

Diagnosing from the server side#

If you have console access (through a hosting control panel, KVM, or out-of-band management), you can diagnose directly on the server.

Check if sshd is running and listening

sudo ss -tlnp | grep ssh

This shows all TCP ports that sshd is listening on. If the output is empty, sshd is not running. If it shows a different port than 22, SSH was configured on that port.

Example output when SSH is running on port 22:

LISTEN  0  128  0.0.0.0:22  0.0.0.0:*  users:(("sshd",pid=1234,fd=3))

Check sshd logs

sudo journalctl -u sshd -n 50

Or on systems that log to files:

sudo tail -50 /var/log/auth.log

or

sudo tail -50 /var/log/secure

The logs show authentication failures, connection drops, and configuration errors. If sshd failed to start, the logs explain why.

Test sshd configuration

Before restarting sshd with a new configuration, validate it:

sudo sshd -t

This checks the configuration file for syntax errors without restarting the service. If there is a problem, it prints the error. If the configuration is valid, it produces no output.

A common scenario: someone edits sshd_config , introduces a typo, and restarts sshd. The restart fails because of the invalid configuration, and now SSH is down. Always run sshd -t before restarting.

Quick troubleshooting checklist#

Run through these steps in order. Most SSH connection refused issues are resolved by one of the first three.

1. Is the hostname correct? Verify with nslookup or dig that the hostname resolves to the expected IP.
2. Is the port correct? Try ssh -p 2222 user@host if the default port 22 is refused. Check with your hosting provider if unsure.
3. Is SSH running? If you have console access: sudo systemctl status sshd . Start it if it is not running.
4. Is the port open in the firewall? Check UFW, firewalld, iptables, and cloud provider security groups.
5. Is your IP banned? Check fail2ban status and /etc/hosts.deny.
6. Is sshd listening on the right interface? Check ListenAddress in sshd_config.
7. Can you reach the server at all? Test other ports (80, 443) to confirm basic network connectivity.
8. Is the configuration valid? Run sshd -t to check for syntax errors.

SSH connection refused on Hostney#

On Hostney, SSH access runs inside an isolated container per account. The SSH connection details (hostname, port, username) are shown in the control panel under Terminal Access.

If you are getting connection refused on Hostney:

Check your connection details. The hostname and port are shown in the control panel. SSH runs on port 22. Make sure you are using the correct hostname for your account.

Check your SSH key. Hostney requires SSH key authentication. Password authentication is not available. If your key is not configured or you are using the wrong key, the connection may be refused at the authentication level. Configure your key through the SSH keys section in the control panel.

Check if your IP was flagged. Hostney’s bot detection system automatically blocks IPs that exhibit brute force behavior across any account on the platform. If your IP was inadvertently flagged (for example, from a script with misconfigured credentials), contact support to have it reviewed.

Check if SSH access is enabled. SSH access is enabled by default, but verify in the control panel that it has not been disabled for your account.

Summary#

“Connection refused” means the server is reachable but nothing is accepting SSH connections on the port you tried. The most common causes are: SSH service not running, wrong port, firewall blocking the port, or your IP being banned after failed login attempts. Start diagnosis by checking port reachability with nc -zv , then work through the checklist from service status to firewall rules to IP bans. Use ssh -vvv for detailed connection debugging and sshd -t to validate server configuration before restarting.