How to fix ssh connection refused port 22: Practical Guide

Understanding SSH Connection Refused Errors

When you attempt to connect via SSH and receive 'connection refused', the TCP handshake reached your server but found no service listening on port 22, or the service rejected the connection. This differs from connection timeout errors, which indicate network-level blocking or unreachable hosts.

The SSH daemon (sshd) must be running and bound to port 22 for connections to succeed. Connection refused means one of three things: the SSH service is stopped, it's listening on a different port, or firewall rules are rejecting the connection before it reaches the service.

Understanding this distinction helps you troubleshoot effectively. Connection refused is a server-side issue, while timeouts typically point to network or cloud provider security group problems.

Check SSH Service Status

For older systems using SysVinit or Upstart:

Check status: sudo service ssh status or sudo /etc/init.d/ssh status

Start if needed: sudo service ssh start

If the service fails to start, check logs immediately with: sudo journalctl -u sshd -n 50 or sudo tail -n 50 /var/log/auth.log to identify configuration errors or missing dependencies.

• Run: sudo systemctl status sshd (or ssh on Debian/Ubuntu)
• Look for 'Active: active (running)' in the output
• If stopped, start with: sudo systemctl start sshd
• Enable automatic startup: sudo systemctl enable sshd

Verify SSH Port Configuration

If SSH is listening on a different port, connect using: ssh -p PORT_NUMBER user@server_ip

If you need to change the port back to 22, edit /etc/ssh/sshd_config, set 'Port 22', then restart sshd. Always maintain console access or a backup connection when modifying SSH settings to avoid lockouts.

• Open: sudo cat /etc/ssh/sshd_config
• Look for the 'Port' directive (uncommented lines without #)
• Default is port 22; if you see 'Port 2222' or another value, SSH is listening elsewhere
• Verify listening ports with: sudo ss -tlnp | grep sshd or sudo netstat -tlnp | grep sshd

Diagnose Firewall Rules

Before making firewall changes, ensure you have console access through your hosting provider's control panel or VNC connection. Incorrect firewall rules can lock you out completely.

• List current rules: sudo iptables -L -n -v
• Look for ACCEPT rules on port 22 or REJECT/DROP rules blocking it
• Add rule if needed: sudo iptables -I INPUT -p tcp --dport 22 -j ACCEPT
• Save rules: sudo iptables-save | sudo tee /etc/iptables/rules.v4 (path varies by distribution)

Check Cloud Provider Security Groups

If your server runs on AWS, Azure, Google Cloud, or another cloud platform, security groups or network ACLs may block port 22 independently of the server's firewall.

For AWS EC2 instances, review Security Groups in the AWS Console. The inbound rules must include an entry allowing TCP port 22 from your IP address (or 0.0.0.0/0 for public access, though IP whitelisting is more secure).

For Azure Virtual Machines, check Network Security Groups (NSGs) attached to your VM's network interface. Ensure an inbound rule permits TCP port 22.

For Google Compute Engine, verify firewall rules in VPC Network settings allow tcp:22 for your instance's network tags.

For DigitalOcean Droplets, check Cloud Firewalls in the Networking section and ensure SSH (port 22) is allowed.

Cloud provider security controls operate before traffic reaches your server, so even if sshd is running and server firewalls allow port 22, connection refused errors can occur if cloud-level rules block the connection.

Validate Network Connectivity and DNS

Check whether you're using the correct hostname or IP address. DNS misconfigurations can cause you to connect to the wrong server entirely. Verify the IP with: host yourdomain.com or nslookup yourdomain.com and confirm it matches your server's actual IP in your hosting panel.

If you recently changed DNS records or migrated servers, DNS propagation delays may direct your SSH client to an old IP where no SSH service exists.

• Ping the server: ping server_ip (Ctrl+C to stop after a few responses)
• Test port 22 specifically: telnet server_ip 22 or nc -zv server_ip 22
• If telnet connects and shows 'SSH-2.0', SSH is reachable but your SSH client may have issues
• If telnet also shows connection refused, the problem is confirmed server-side

Advanced Troubleshooting and Prevention

For SELinux issues, verify SSH context: sudo semanage port -l | grep ssh. If port 22 is not listed or SSH is confined, temporarily set SELinux to permissive mode for testing: sudo setenforce 0 (restore with setenforce 1 after diagnosis).

Prevent future connection refused errors by:

• Monitoring SSH service with uptime checks or process monitoring tools
• Enabling SSH daemon automatic restart on failure: sudo systemctl enable sshd
• Documenting custom port configurations and firewall rules in your runbook
• Maintaining console access credentials for your hosting provider's emergency console
• Testing SSH access after system updates or firewall changes before closing your current session