How to fix ssh: connect to host hostname port 22: Connection refused in SSH

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 172 views

This error occurs when your SSH client cannot establish a connection to the remote server on port 22. It typically indicates the SSH service is not running, the port is blocked by a firewall, or the server is unreachable.

Quick fix

Fixes ssh: connect to host hostname port 22: Connection refused

ping <server_ip_or_hostname>
  1. Verify network connectivity to the server
  2. Check if SSH service is running on the remote server
  3. Start the SSH service
  4. Verify the SSH port configuration
ssh — error
ping <server_ip_or_hostname>
ssh: connect to host hostname port 22: Connection refused

What this error means

The SSH connection refused error means that your SSH client attempted to connect to a remote server but received an explicit refusal response. This typically happens when the SSH daemon (sshd) is not listening on the specified port, the network path to the server is blocked, or the service has crashed. Unlike a timeout error, 'connection refused' indicates that the server received your connection request but actively rejected it, meaning the network is reachable but the SSH service is not available.

Typical symptoms

  • SSH connection fails immediately with 'Connection refused' message
  • Cannot connect to remote servers for any purpose
  • Local network tools like ping may work, but SSH fails
  • Connection works from some networks but fails from others
  • SSH worked previously but stopped working after a server restart

Common causes

  1. SSH service (sshd) is not running on the remote server
  2. SSH server is listening on a non-standard port (not port 22)
  3. Firewall (ufw, iptables, firewalld) is blocking port 22
  4. Network connectivity issue between client and server
  5. Wrong hostname or IP address in connection command
  6. SSH service crashed or failed to start on server boot

How to fix "ssh: connect to host hostname port 22: Connection refused"

1Verify network connectivity to the server

First, confirm the remote server is reachable on the network using ping:

bash
ping <server_ip_or_hostname>

If ping fails, there's a network connectivity issue. Check your network connection, VPN, or firewall rules between your client and the server. If you're connecting through a proxy or jump host, verify that configuration is correct.

2Check if SSH service is running on the remote server

Log in to the remote server locally or through another method (console, remote desktop) and check if the SSH daemon is running:

bash
sudo systemctl status ssh

Or on some systems:

bash
sudo systemctl status sshd

If the service is inactive, stopped, or dead, the SSH daemon is not running and needs to be started.

3Start the SSH service

If SSH is not running, start it immediately and enable it to start automatically on boot:

bash
sudo systemctl start ssh
sudo systemctl enable ssh

Or use the older service syntax:

bash
sudo service ssh start

After starting, verify it's running with the status command from the previous step. Then try your SSH connection again.

4Verify the SSH port configuration

Check what port the SSH server is listening on. By default it's port 22, but some administrators change this for security:

bash
grep Port /etc/ssh/sshd_config

If it shows a port other than 22, connect using that port:

bash
ssh -p <port_number> user@hostname

Also check if SSH is actually listening on that port:

bash
sudo netstat -tlnp | grep ssh

or

bash
sudo ss -tlnp | grep ssh
5Check and configure firewall rules

The server's firewall may be blocking SSH connections. Check your active firewall and add a rule to allow port 22:

For UFW (Ubuntu/Debian):

bash
sudo ufw status
sudo ufw allow 22
sudo ufw reload

For firewalld (CentOS/RHEL):

bash
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

For iptables (manual rules):

bash
sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

Note: This is not persistent across reboots. Consider using UFW or firewalld instead.

6Test SSH port connectivity from your client

Use telnet or nc (netcat) to verify the port is open and listening:

bash
telnet <server_ip> 22

or

bash
nc -zv <server_ip> 22

A successful response means the port is open. If it times out or refuses, the port is blocked or not listening.

7Check SSH logs on the server for errors

If SSH is running but still refusing connections, check the SSH service logs for configuration errors or crash messages:

bash
sudo tail -f /var/log/auth.log

or on Red Hat/CentOS:

bash
sudo tail -f /var/log/secure

Or use journalctl:

bash
sudo journalctl -u ssh -n 50
sudo journalctl -u sshd -n 50

Look for errors related to port binding, configuration parsing, or permission issues.

8Try connecting with verbose output

Use SSH verbose mode to see detailed connection attempts and identify where the connection fails:

bash
ssh -vvv user@hostname

With three -v flags, you'll see:
- Connection attempt details
- Which port is being tried
- Protocol negotiation
- Authentication attempts

This output often reveals whether the connection is being refused at the network level or by the SSH service itself.

Advanced notes

Cloud VMs (AWS, Azure, GCP): If connecting to cloud-hosted instances, verify that security groups, network security groups, or firewall rules allow inbound traffic on port 22 from your IP. The SSH service may be running, but network-layer security policies can prevent connections from reaching it.

SSH Key vs Password: Connection refused errors apply to both password and key-based authentication. If you recently changed authentication methods, verify the correct keys are deployed and permissions on ~/.ssh are correct (700 for the directory, 600 for private keys).

SELinux or AppArmor: On systems with mandatory access controls, SELinux or AppArmor policies can prevent sshd from binding to the port. Check denial logs: sudo tail /var/log/audit/audit.log for SELinux or sudo journalctl -u apparmor for AppArmor.

Zombie Processes: If sshd processes are stuck (zombie state), kill them and restart: sudo pkill -9 sshd; sudo systemctl start ssh

IPv4 vs IPv6: By default sshd listens on both IPv4 and IPv6. If you can't connect via IPv4 but IPv6 works (or vice versa), check the ListenAddress directives in /etc/ssh/sshd_config.

Frequently asked questions

What does "ssh: connect to host hostname port 22: Connection refused" mean?
The SSH connection refused error means that your SSH client attempted to connect to a remote server but received an explicit refusal response. This typically happens when the SSH daemon (sshd) is not listening on the specified port, the network path to the server is blocked, or the service has crashed. Unlike a timeout error, 'connection refused' indicates that the server received your connection request but actively rejected it, meaning the network is reachable but the SSH service is not available.
How do I fix "ssh: connect to host hostname port 22: Connection refused"?
This error occurs when your SSH client cannot establish a connection to the remote server on port 22. It typically indicates the SSH service is not running, the port is blocked by a firewall, or the server is unreachable.
What causes "ssh: connect to host hostname port 22: Connection refused"?
SSH service (sshd) is not running on the remote server SSH server is listening on a non-standard port (not port 22) Firewall (ufw, iptables, firewalld) is blocking port 22
Is the "ssh: connect to host hostname port 22: Connection refused" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading