A "connection refused" error when using SSH means the remote server is actively rejecting the incoming connection attempt, usually because no service is listening on the expected port or a firewall is blocking it. Since you can ping the server and SSH localhost works, your network connectivity and local SSH client are functional. The issue lies in the remote server's configuration, specifically whether the SSH daemon (sshd) is running, if it is bound to the correct IP address, or if an intermediate firewall like UFW or iptables is dropping the packets before they reach the application.
Verify the SSH Service Status
The most common cause of this error is that the SSH daemon is not running on the target machine. Even if the operating system is up and responding to pings, the specific background process handling SSH connections might be stopped or disabled. You need to access the remote server through an alternative method, such as the cloud provider’s console, physical access, or another management tool, to check the service status.
On Linux systems using systemd, which is standard for most modern distributions including Ubuntu and CentOS, you can check the status with the following command:
sudo systemctl status sshd
If the service is inactive or failed, you will see a red indicator or a message stating it is not running. To start the service immediately, use:
sudo systemctl start sshd
To ensure it starts automatically on boot, enable it with:
sudo systemctl enable sshd
If you are using an older system with SysVinit, you would use
service sshd status and
service sshd start. Note that on some Debian-based systems, the service name might be
ssh instead of
sshd. Always verify the exact service name by checking the installed packages or looking at the processes list with
ps aux | grep ssh.
Check Firewall Rules
If the SSH service is running but you still get a connection refused error, a firewall is likely blocking the connection. Unlike "connection timed out," which suggests a packet was lost or dropped silently, "connection refused" often indicates that the packet reached the host but was rejected by a local firewall rule.
Common firewalls include UFW (Uncomplicated Firewall) on Ubuntu, firewalld on CentOS/RHEL, or iptables directly. Check your active rules. For UFW, run:
sudo ufw status
Look for a line allowing traffic on port 22 (the default SSH port). If it is missing or set to deny, add the rule:
sudo ufw allow 22/tcp
For firewalld, you can check zones and services with:
sudo firewall-cmd --list-all
Ensure that the
ssh service is listed in the active zone. If not, add it with:
sudo firewall-cmd --permanent --add-service=ssh
Then reload the firewall configuration:
sudo firewall-cmd --reload
Remember that cloud providers like AWS, Azure, and Google Cloud also have their own security groups or network ACLs. These act as an external firewall. If the instance-level firewall allows SSH, but the cloud provider’s security group does not have an inbound rule for TCP port 22, the connection may fail differently depending on the provider. However, if the provider drops the packet silently, you typically get a timeout. A strict "refused" error usually points to the OS-level firewall or the service binding.
Inspect SSH Daemon Configuration
The SSH daemon itself might be configured to listen only on specific interfaces or IP addresses. By default, it listens on all available IPv4 and IPv6 interfaces. However, if the
ListenAddress directive in the configuration file is set incorrectly, it will refuse connections from other IPs.
Edit the main configuration file, typically located at
/etc/ssh/sshd_config, using a text editor like nano or vim:
sudo nano /etc/ssh/sshd_config
Search for the line starting with
ListenAddress. If it is commented out (preceded by a #), it defaults to all interfaces. If it is uncommented, ensure it is set to
0.0.0.0 for IPv4 or
:: for IPv6, or remove the line entirely to revert to defaults. After making changes, restart the service:
sudo systemctl restart sshd
Additionally, check the
Port directive. If the server is configured to listen on a non-standard port, such as 2222, you must specify that port in your SSH client command. Connecting to port 22 when the server is on 2222 will result in a connection refused error because nothing is listening on 22.
For more details on fixing similar issues on fresh installs, see our guide on
Troubleshooting SSH Connection Issues on a Fresh Install of Ubuntu Server 23.10 on a Raspberry Pi.
Test Connectivity and Diagnostics
Once you have verified the service is running, the firewall is open, and the configuration is correct, test the connection again. Use the verbose flag to get detailed output about where the connection fails:
ssh -v user@remote_server_ip
Look for the line that says "Connection refused." If it appears after attempting to connect to port 22, the issue persists. You can also use
telnet or
nc (netcat) to test if the port is open without initiating an SSH handshake:
nc -zv remote_server_ip 22
If netcat reports "Connection refused," the problem is definitely at the network or service level. If it reports "Connected," then the issue might be related to SSH protocol versions or key exchange errors, which are different from a simple refusal.
In some cases, SELinux (Security-Enhanced Linux) can interfere with SSH. While rare for basic connectivity, mislabeled ports can cause issues. Check SELinux status with
getenforce. If it is enforcing, you may need to adjust contexts, though this usually results in permission denied errors rather than connection refused.
If you suspect the SSH key authentication is causing early termination, check the server logs. On the remote server, view the auth log:
sudo tail -f /var/log/auth.log
Or on RHEL/CentOS:
sudo tail -f /var/log/secure
This real-time log will show exactly why the connection is being dropped. For related authentication issues, refer to
Troubleshooting kex_exchange_identification Error in Linux SSH Connection.
Consider Alternative Access Methods
If you cannot resolve the issue via SSH, consider using alternative management tools provided by your hosting environment. Most cloud providers offer web-based consoles or serial console access. This allows you to interact with the terminal directly through the browser, bypassing network restrictions entirely.
From there, you can debug the SSH service, check disk space, review system logs, and restart services without relying on network connectivity. This is particularly useful if the SSH configuration is broken beyond easy repair or if the network interface has been misconfigured.
Frequently Asked Questions
Why does ping work but SSH fails?
Ping uses ICMP protocol, while SSH uses TCP on port 22. Firewalls often allow ICMP for diagnostics but block specific TCP ports for security. Additionally, the SSH service might be down even if the OS is responsive to pings.
How do I know if my firewall is blocking SSH?
Use the
nc -zv ip port command. If it returns "Connection refused," the host is reachable but rejecting the port. If it hangs or times out, the packet is being dropped by a firewall or blocked by a security group.
Can a wrong SSH port cause connection refused?
Yes. If the server listens on port 2222 but you try to connect to port 22, the client will receive a refusal because no service is listening on 22. Always verify the port in
/etc/ssh/sshd_config.
What should I do if SSH service won't start?
Check the configuration syntax for errors using
sshd -t. If there are syntax errors in
sshd_config, the service will fail to start. Fix the errors identified by the test command and try restarting again.
Does SELinux cause connection refused errors?
SELinux typically causes "Permission Denied" errors after a connection is established. However, incorrect port labeling can sometimes prevent the service from binding correctly, leading to refusal. Check SELinux logs with
ausearch -m avc -ts recent if other fixes fail.