SSH Connection Refused - Troubleshooting Guide

When SSH reports "Connection Refused" despite a successful ping, the remote server is actively rejecting the TCP handshake because no service is listening on port 22 or a firewall is dropping the packets. This guide details how to verify the SSH daemon status, check local and remote firewalls, and inspect network routing to restore connectivity.

Verify the SSH Daemon Status

The most common cause for this error is that the sshd service is not running on the target machine. Even if the server responds to ICMP echo requests (ping), it will reject any attempt to establish an SSH connection if the background process is stopped or crashed. You must have console access to the remote server, such as via a cloud provider’s web console or physical keyboard, to diagnose this. First, check if the service is active using the system initialization tool. On modern Linux distributions using systemd, run:

systemctl status sshd

If the output indicates the service is inactive or failed, start it immediately with:

sudo systemctl start sshd

To ensure it starts automatically after a reboot, enable the service:

sudo systemctl enable sshd

On older systems using SysVinit, you might need to use service ssh start. If the service is running but still refuses connections, check the logs for errors during startup by viewing /var/log/auth.log or /var/log/secure. Misconfigured host keys or invalid configuration files in /etc/ssh/sshd_config can prevent the daemon from binding to the socket.

Check Firewall Rules

If the daemon is running, the next likely culprit is a firewall blocking incoming traffic on port 22. Firewalls operate at the network layer and can drop packets before they reach the application layer, resulting in a timeout rather than a refusal, but some configurations explicitly send a TCP RST packet, which triggers the "Connection Refused" message locally. On the remote server, inspect the active firewall rules. For ufw (Uncomplicated Firewall) commonly used on Ubuntu, check the status with:

sudo ufw status

Ensure there is a rule allowing traffic from your IP address or all sources to port 22. If the status shows inactive, the firewall is not the issue. However, if it is active, allow SSH with:

sudo ufw allow ssh

For iptables users, list the rules to see if port 22 is accepted:

sudo iptables -L -n -v

Look for a chain named INPUT that accepts TCP traffic on dport 22. If you are managing a cloud instance, remember that cloud providers also have security groups or network ACLs configured at the hypervisor level. These act as an external firewall. Log into your cloud provider’s dashboard and verify that inbound rules permit TCP traffic on port 22 from your current public IP address.

Inspect Network Configuration and Binding

Sometimes the SSH daemon is running and the firewall is open, but the service is bound to a specific network interface that does not include your source IP. By default, sshd listens on all interfaces (0.0.0.0). However, administrators may restrict it to localhost (127.0.0.1) for security reasons. Check the ListenAddress directive in /etc/ssh/sshd_config. If it is set to 127.0.0.1, remote connections will be refused. Change this to 0.0.0.0 or comment out the line to listen on all interfaces, then restart the service. Additionally, verify the port number. While 22 is standard, some servers change the port to avoid automated bots. If you recently changed the port, you must specify it in your client command:

ssh -p 2222 user@remote_host

If you are connecting through a proxy or NAT device, ensure that port forwarding is correctly configured. A mismatched port mapping between the router and the internal server IP will result in connection failures.

Diagnostic Steps When Local Login Works

The original problem statement mentions being able to login locally. This confirms the OS is functional and the user account exists. It isolates the issue to network accessibility. Use telnet or nc (netcat) from the client machine to test the raw TCP connection to the remote port.

nc -zv remote_host 22

If this fails with "Connection refused," the issue is definitely on the server side (daemon down, firewall, or binding). If it hangs or times out, the packet is being dropped by a firewall or routed incorrectly. If it succeeds, but SSH still fails, check for DNS resolution issues or incorrect hostname entries in /etc/hosts. For more complex scenarios involving virtualization or multi-hop setups, refer to our guide on WSL2: SSH Server on Ubuntu not Working, which addresses similar binding issues in containerized environments. Another relevant resource is Troubleshooting SSH WSL Machine: Can't Connect to Localhost, which helps if your local environment is misconfiguring the loopback adapter.

Frequently Asked Questions

Why can I ping the server but SSH is refused?

Ping uses ICMP protocol, while SSH uses TCP. A server can be configured to respond to pings while blocking or not running the SSH service on port 22. This discrepancy indicates the network path is open, but the specific application service is unavailable or restricted.

How do I check if port 22 is open from my client?

Use the netcat command nc -zv ip_address 22 or telnet telnet ip_address 22. If these tools report a successful connection, the network path is clear, and the issue lies within the SSH configuration or authentication methods on the server.

What if I changed the SSH port but forgot to update my client?

You must explicitly specify the new port using the -p flag followed by the port number in your SSH command. Without this flag, the client defaults to port 22 and will receive a connection refused error if the server is only listening on a different port.

Can a VPN cause SSH connection refused errors?

Yes, if your VPN routes traffic differently or blocks certain ports, it may interfere with the connection. Additionally, if the VPN splits tunneling incorrectly, your client might try to connect to a local gateway instead of the remote server, leading to refusal if no SSH service runs on the gateway.

Is it safe to disable the firewall entirely to fix this?

No, disabling the firewall entirely exposes your server to all incoming traffic, including brute-force attacks. Instead, create specific rules to allow only necessary ports like 22 from trusted IP ranges. Always keep the firewall enabled and manage access through precise allow-lists.