When you attempt to connect via SSH and see the message ssh connect to host port 22 connection refused, it means no service is actively listening on that port or a firewall is blocking the path. This symptom often points to a misconfigured server, a stopped daemon, or network filtering rules that prevent the standard SSH port from being reached.
Below is a quick reference table to distinguish common causes, related ports, and immediate checks you can run to narrow down the issue.
| Cause | Likely Port State | Quick Diagnostic Command | Typical Resolution |
|---|---|---|---|
| SSH daemon not running | Closed / Filtered | systemctl status sshd | Start or restart the service |
| SSH configured on non-standard port | Port 22 closed, other port open | ss -tlnp | grep ssh | Connect using the configured port |
| Firewall dropping or rejecting port 22 | allowPort 22 filtered | iptables / ufw status | Allow port 22 or adjust rules |
| Host unreachable or network issue | No response | ping, traceroute, mtr | Check routing, interfaces, and ACLs |
Understanding SSH Port 22 Connection Refused
The default SSH port 22 connection refused response is a clear signal from the target host or network that your packets cannot establish a TCP session. Unlike a timeout, which suggests no reply at all, connection refused indicates that the host is reachable but explicitly rejecting the connection because there is no application bound to that port.
This behavior is intentional for security, but in production environments it often points to a configuration drift, a failed service update, or overly aggressive firewall policies. Recognizing the exact network path and host state helps you resolve the issue faster and avoid unnecessary guesswork.
Common operational triggers include a service crash after a failed package upgrade, a change in the SSH configuration file without a service reload, or an automated firewall rule applied during cloud image creation. Pinpointing the root cause requires combining service status, port listening checks, and path trace data.
Check If SSH Service Is Running
Before diving into network diagnostics, verify that the SSH daemon is actually up on the server. Many administrators assume the service is running, but automated deployments, crash recovery, or maintenance scripts can leave it stopped.
Verify Service Status and Logs
On systemd-based systems, run systemctl status sshd or systemctl status ssh to see whether the process is active. Cross-check with journalctl -u sshd -n 50 to capture recent log entries around start or failure events. If the service is inactive, start it with systemctl start sshd and enable it for boot with systemctl enable sshd.
Confirm Listening Ports
Use ss -tlnp or netstat -tlnp to list local TCP listeners and confirm that sshd is bound to the expected port. If you see it listening on a non-standard port, adjust your client command accordingly with ssh -p
Diagnose Network Path and Firewall Rules
Even when the SSH daemon is healthy, network devices or host-based firewalls can drop or reject packets bound to port 22. Connection refused differs from no response, but it can still arise from strict ingress or egress policies.
Validate Local Firewall Settings
On Linux hosts, inspect rules with ufw status numbered or iptables -L -n to see whether port 22 is allowed. On cloud platforms, verify security group or network ACL settings to ensure inbound TCP/22 is explicitly permitted from your IP range. Temporarily relaxing rules for testing can confirm whether filtering is the cause, but remember to restore secure restrictions afterward.
Trace the Network Path
Use ping to confirm basic reachability and traceroute or mtr to identify where packets stop or change behavior. Some environments block ICMP entirely, so combine these with TCP probes using tools like tcptraceroute to ssh port 22. If hops along the path drop or alter packets, involve your network or cloud provider to review routing and filtering policies.
Common Configuration and Deployment Pitfalls
In dynamic infrastructures, SSH port issues often surface after automated builds, image updates, or scaling events. Standard templates might ship with different network settings or service configurations that diverge from production expectations.
Review Configuration Management
Check playbooks, scripts, or cloud-init files for tasks that modify sshd_config, change ports, or restart the service conditionally. Ensure that key regeneration steps do not overwrite certificates required for authentication, and verify that SELinux or AppArmor profiles permit SSHd to bind and listen on the intended interface.
Plan for Port Changes and Failover
If you intentionally run SSH on a non-standard port, document the change across teams and update automation tooling. For high availability, use load balancers or bastion hosts that expose the expected ports while backend instances may run custom values. Maintain at least one authorized recovery method, such as console access or a jump host, to prevent accidental lockouts during transitions.
Operational Best Practices for Reliable SSH Access
- Verify sshd status and listening ports before and after updates or configuration changes.
- Use infrastructure-as-code to enforce consistent SSH settings across environments.
- Maintain alternative access paths, such as console or bastion, for recovery.
- Monitor service health and port reachability with alerts for unexpected closed states.
- Document port changes, firewall rules, and recovery procedures for faster troubleshooting.
FAQ
Reader questions
Why do I get connection refused on port 22 while other services on the same host respond normally?
The SSH daemon is either not running, not bound to the expected interface, or blocked by a firewall, whereas other services have their own listeners and rules. Check the SSH service status, listening ports, and host firewall configuration to isolate the issue.
Could a misconfigured sshd_config cause ssh connect to host port 22 connection refused even when the service appears up?
Yes, settings such as ListenAddress, Port, or BindAddress can restrict which interfaces or ports sshd accepts connections on. A typo or overly restrictive value may cause the daemon to bind to a different port or interface, making port 22 appear closed.
Is it safe to open port 22 directly to the internet to resolve connection refused errors?
Opening port 22 to the internet increases exposure to automated attacks. Prefer restrictive source ranges, key-based authentication, and non-standard ports where appropriate. Combine with fail2ban, firewall rate limiting, and bastion access to reduce risk while maintaining connectivity.
How can I quickly test whether the issue is on my client or the remote host when port 22 is refused?
Run the same SSH command from another network or host, and use tools like telnet or nc to test connectivity to port 22. If those tests also result in connection refused, the issue is likely server-side; if they succeed, refine your client configuration and credentials.