SSH connection refused means no service is listening on the port, or a firewall is blocking. Six fixes, in order: check sshd is running, check the port, check the firewall, check SELinux/AppArmor, check the IP, and check sshd_config. The right answer is to walk through the list in order — the cause is usually the first or second item. The team that has this checklist has the fix in under five minutes.
Table of contents
- The error and what it means
- Fix 1: Check sshd is running
- Fix 2: Check the port
- Fix 3: Check the firewall
- Fix 4: Check SELinux or AppArmor
- Fix 5: Check the IP address
- Fix 6: Check sshd_config
- FAQ
The error and what it means
The Connection refused error means the kernel received the TCP SYN packet and returned a RST. The reason is always one of two things: no service is listening on the port, or a firewall is rejecting the connection with a RST.
The right answer is to start with the simple checks and escalate. The wrong answer is to assume the server is down or that the network is broken — Connection refused means the server is reachable but the port is closed.
Fix 1: Check sshd is running
The right command on the server:
sudo systemctl status sshdIf sshd is not running:
sudo systemctl start sshd
sudo systemctl enable sshdThe right answer for the auto-start on reboot is enable. The wrong answer is to start it and forget to enable it, then lose remote access after a reboot.
Fix 2: Check the port
The right command on the server to see what is listening:
sudo ss -tlnp | grep sshThe right answer is to see LISTEN on port 22 (or your custom port). If the port is not listed, sshd is not listening. The wrong answer is to assume the default port — the right answer is to check the actual config.
The right command to check the listening port in sshd_config:
grep ^Port /etc/ssh/sshd_configThe right answer is to use that port on the client. The wrong answer is to use port 22 by default.
Fix 3: Check the firewall
The right answer for the firewall depends on the distro. On Ubuntu with UFW:
sudo ufw status
sudo ufw allow 22/tcpOn RHEL / Fedora / CentOS Stream with firewalld:
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadOn cloud providers (AWS, GCP, Azure), the right answer is also to check the security group or network ACL. The wrong answer is to assume the host firewall is the only one — cloud providers have their own security groups in front of the VM.
Fix 4: Check SELinux or AppArmor
On RHEL / Fedora / CentOS Stream, the right answer is to check if SELinux is blocking sshd:
sudo ausearch -m avc -ts recent | grep sshdIf SELinux is blocking, the fix is usually to restore the SELinux context on sshd’s files or to set the right SELinux boolean. The right command to see what sshd needs:
sudo semanage port -l | grep sshIf the port is non-standard, the right answer is to add it to SELinux:
sudo semanage port -a -t ssh_port_t -p tcp 2222On Ubuntu with AppArmor, the right answer is to check sudo journalctl -k | grep -i apparmor for denials. The wrong answer is to disable SELinux or AppArmor — the right answer is to fix the policy.
Fix 5: Check the IP address
The right answer is to verify you are connecting to the right IP. The wrong answer is to assume DNS is correct. The right command to check:
nslookup server.example.comOr from the client, use getent hosts server.example.com. The right answer is to verify the IP matches the server’s actual IP (ip a on the server).
Fix 6: Check sshd_config
The right command to verify sshd_config syntax:
sudo sshd -tThis is the SSH test mode — it reports syntax errors without actually starting sshd. The right answer is to run this after any change to sshd_config. The wrong answer is to reload sshd with a broken config — the wrong answer is to lock yourself out of the box.
The right answer is to also check ListenAddress in sshd_config. If sshd is bound to a specific address, connections to other addresses will be refused. The right command:
grep ^ListenAddress /etc/ssh/sshd_configIf the address is wrong, the right answer is to comment out the line (default listens on all addresses) or to set it to the right address.
FAQ
What is the difference between ‘connection refused’ and ‘connection timed out’?
Connection refused means the server is reachable but the port is closed. Connection timed out means the server is unreachable (firewall dropping packets, network issue, or server down). The right answer is to debug them differently. Refused is local; timed out is network.
What about ‘no route to host’?
Means the network is unreachable. The right answer is to check the routing on both ends (ip route on the client, ip route on the server) and check for missing routes or wrong default gateways.
How do I know if sshd is bound to a specific IP?
sudo ss -tlnp | grep ssh shows the local address and port. If it shows 0.0.0.0:22, it’s listening on all addresses. If it shows 192.168.1.10:22, it’s bound to a specific IP. The right answer is to set ListenAddress 0.0.0.0 to listen on all addresses.
My cloud provider says the security group allows SSH, but it is still refused. What now?
The right answer is to check the OS firewall (iptables, nftables, firewalld) inside the VM, and check the VPC network ACLs (AWS) or subnet firewalls. The wrong answer is to assume the security group is the only firewall.
What if sshd is running but the port is not listening?
The right answer is to check if sshd is bound to a specific IP that is not on the current interface, or if the Port directive in sshd_config is set to a non-standard value. The wrong answer is to keep restarting sshd — the config issue will not change.
How do I temporarily allow SSH from anywhere to test?
On the server’s firewall, sudo ufw allow from any to any port 22. The right answer is to revert this after the test, not to leave it open.
What is the difference between ‘connection reset’ and ‘connection refused’?
Connection reset means the server actively closed the connection (RST during data exchange). The right answer is to look at the server logs for the reason. Connection refused means no service was listening on the port at all.
How do I see what port sshd is actually using?
sudo ss -tlnp | grep ssh or netstat -tlnp | grep ssh. The right answer is to look at the local_address column, which shows the IP:port. The right answer for a non-standard port is to use that port on the client.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: