How to fix ssh connection refused port 22: Troubleshooting Checklist

Understanding Connection Refused vs Other SSH Errors

Connection refused means the TCP handshake reached the target machine, but nothing was listening on port 22 to accept the connection. This is fundamentally different from other SSH errors and narrows down where to look.

If you see a timeout instead, the packets never reached the server or no response came back—pointing to network-level issues, incorrect IP addresses, or cloud security groups blocking traffic. If you see 'Connection reset by peer' or 'No route to host,' those indicate different failure modes entirely.

The 'connection refused' message confirms network routing is working and the server is reachable, so your troubleshooting should focus on the SSH service state, local firewall rules, and port configuration rather than network-layer problems.

Check if SSH Service is Running

The most common cause of connection refused on port 22 is that the SSH daemon (sshd) is not running. This happens after a failed service restart, system reboot without auto-start enabled, or manual shutdown.

If you have console access through your hosting provider's control panel or IPMI, log in directly and check the service status. On systemd-based systems (Ubuntu 16.04+, CentOS 7+, Debian 8+), run: systemctl status sshd or systemctl status ssh depending on the distribution.

If the service is inactive or failed, check the service logs for errors: journalctl -u sshd -n 50. Common failures include configuration syntax errors in /etc/ssh/sshd_config, missing host keys, or permission problems on key files. Once you've addressed the underlying issue, start the service with: sudo systemctl start sshd and enable it to start on boot: sudo systemctl enable sshd.

On older init-based systems, use: service sshd status and service sshd start. If you don't have console access and can't reach the server, contact your hosting provider to restart the SSH service from their side.

Verify SSH is Listening on Port 22

Even if the SSH service is running, it may be configured to listen on a non-standard port. Check which port sshd is actually using by running: sudo ss -tlnp | grep sshd or sudo netstat -tlnp | grep sshd.

Look for a line showing the process listening on 0.0.0.0:22 or :::22. If you see a different port number like 2222 or 2200, that's your answer—the SSH daemon was reconfigured to use that port instead. Update your SSH client command to specify the correct port: ssh -p 2222 user@hostname.

If nothing is listening on any port, the service isn't actually running despite what systemctl might show. This can happen if sshd failed to bind due to an address conflict or permission issue. Check /var/log/auth.log or journalctl -u sshd for bind errors.

To change the SSH port back to 22, edit /etc/ssh/sshd_config, find the Port directive, set it to 22, then restart sshd. Before doing this, ensure port 22 isn't already in use by another service.

Inspect Firewall Rules Blocking Port 22

A local firewall on the server can block port 22 even when sshd is running and listening. The two most common firewall tools on Linux are iptables and its frontend ufw (Uncomplicated Firewall), plus firewalld on RHEL-based systems.

Check ufw status with: sudo ufw status verbose. If it shows active and port 22 is not listed in the allowed rules, add it: sudo ufw allow 22/tcp. If you changed SSH to a custom port, allow that port instead and consider removing the old rule.

For iptables directly, list current rules: sudo iptables -L -n -v. Look for a DROP or REJECT rule affecting port 22 in the INPUT chain. To allow SSH, insert a rule: sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT. Remember to save the rules so they persist after reboot: sudo iptables-save > /etc/iptables/rules.v4 or use your distribution's persistence mechanism.

On firewalld systems (CentOS, Fedora, RHEL), check with: sudo firewall-cmd --list-all. Add SSH if missing: sudo firewall-cmd --permanent --add-service=ssh followed by sudo firewall-cmd --reload.

Before modifying firewall rules, document the current state and have a backup access method. Locking yourself out by misconfiguring the firewall is a common issue. If possible, test rule changes without making them permanent first.

Check Cloud and Hosting Security Groups

If you're running on a cloud platform like AWS, Google Cloud, Azure, DigitalOcean, or Linode, a security group or network firewall at the infrastructure level may be blocking port 22 before traffic even reaches your server's local firewall.

Log into your cloud provider's control panel and locate the security group or firewall configuration attached to your instance. Verify there's an inbound rule allowing TCP traffic on port 22 from your IP address or from 0.0.0.0/0 if you need global access.

For AWS EC2, check the security group's inbound rules. For Google Cloud, check VPC firewall rules. For Azure, inspect Network Security Groups. Each platform has a slightly different interface, but the concept is the same: ensure port 22 TCP is explicitly allowed.

If you recently created the instance from a template or snapshot, the security group may have inherited restrictive rules. Create a new rule allowing SSH or modify the existing group. Changes typically take effect immediately, but test from a different network if possible to confirm external accessibility.

Validate Network Routing and DNS Resolution

While connection refused usually means the packets reached the server, it's worth confirming you're connecting to the correct IP address. Use: ping hostname and verify the resolved IP matches your server's actual address. DNS propagation issues or stale records can direct you to the wrong machine.

If you're connecting through a VPN, proxy, or NAT gateway, confirm the routing allows outbound connections to port 22. Some corporate and public networks block SSH traffic entirely. Test from a different network (mobile hotspot, different ISP) to rule out client-side restrictions.

Use telnet or nc to test raw TCP connectivity: telnet server-ip 22 or nc -zv server-ip 22. If you get 'Connection refused,' the server actively rejected it. If you get a timeout, packets aren't reaching the server. If you see 'Connected' or an SSH version banner, port 22 is open and sshd is responding—indicating the issue may be with your SSH client configuration or keys.

For IPv6-enabled servers, ensure you're connecting over the correct protocol. Some configurations listen on IPv4-only or IPv6-only. Explicitly specify the address family if needed: ssh -4 user@hostname or ssh -6 user@hostname.

Review SSH Configuration and Restart Safely

Syntax errors in /etc/ssh/sshd_config can prevent sshd from starting or cause it to reject connections. Before restarting SSH after any configuration change, test the config file: sudo sshd -t. This validates syntax without disrupting the running service.

Common misconfigurations include: PermitRootLogin set to 'no' when you're trying to connect as root, AllowUsers or AllowGroups restrictions that exclude your username, and ListenAddress directives that bind to the wrong interface.

If you must restart sshd, keep your current session open and test the new connection in a separate terminal before closing your existing session. This prevents lockout if the restart fails. Use: sudo systemctl restart sshd then immediately test: ssh user@hostname in another window.

For mission-critical systems, consider setting up a secondary SSH daemon on an alternate port as a backup access method before making changes to the primary service. Clone the sshd configuration, change the port, and run a second instance.