SSH Connection Refused: Causes and Fixes

You try to log in and SSH stops immediately with connect to host example.com port 22: Connection refused. The failure happens before SSH checks your key or password, so changing authentication settings will not fix it.

An immediate refusal means the target address has no process listening on that port, or a firewall or network device actively rejected the request. The usual causes are a stopped SSH server, the wrong host or port, a listener bound to another address, a firewall reject rule, or port forwarding to the wrong machine. A connection that hangs and then times out is different because no response came back.

This guide starts with checks you can run from the client, then moves to the SSH service, listening port, firewall, and network path on the server.

Quick Reference #

For a printable quick reference, see the SSH cheatsheet .

Confirm the Host and Port from the Client #

Before changing the server, confirm that the hostname resolves to the address you expect:

getent ahosts example.com

If the result points to an old server or the wrong public address, correct the DNS record or connect to the intended IP address directly. Reaching the wrong host can produce a refusal even when SSH is working on the real server.

Next, run SSH with verbose output:

ssh -vvv user@example.com

The relevant lines look like this:

debug1: Connecting to example.com [203.0.113.10] port 22.
ssh: connect to host example.com port 22: Connection refused

The client resolved example.com to 203.0.113.10 and received an immediate refusal from port 22. You can test the TCP port without starting an SSH login:

nc -vz example.com 22

If the server uses a custom port, test and connect to that port instead:

nc -vz example.com 2222
ssh -p 2222 user@example.com

A hostname can also have separate IPv4 and IPv6 addresses. Test each address family when one DNS record may point to the wrong server:

ssh -4 user@example.com
ssh -6 user@example.com

The remaining checks require access to the server through a cloud console, virtual machine console, physical terminal, or another management channel.

Check Whether SSH Is Listening #

The listening socket is the quickest way to tell whether the server can accept SSH connections on port 22. Run this command on the server:

sudo ss -ltnp 'sport = :22'

A working listener appears as either sshd or systemd, depending on whether the distribution runs the daemon continuously or uses socket activation. If the command returns nothing, no process is accepting connections on port 22.

To see the port and addresses from the effective OpenSSH configuration, run:

sudo sshd -T | grep -E '^(port|listenaddress) '

Typical output looks like this:

port 22
listenaddress [::]:22
listenaddress 0.0.0.0:22

The output shows that SSH is configured for port 22 on all IPv6 and IPv4 addresses. If it reports another port, connect with the -p option and verify that the firewall allows that port. See our guide on changing the SSH port if you need to correct the configuration.

Check the SSH Service or Socket #

Linux distributions use different systemd unit names for OpenSSH. Ubuntu and Debian use ssh.service, while Fedora, RHEL, and their derivatives use sshd.service.

On Ubuntu and Debian, check the service:

sudo systemctl status ssh.service

Ubuntu 22.10 and later use ssh.socket by default, so check that unit as well:

sudo systemctl status ssh.socket

When ssh.socket is active and owns port 22, ssh.service may remain inactive until a client connects. In that setup, an inactive service alone does not indicate a problem. If the socket is disabled or stopped, enable it and start it:

sudo systemctl enable --now ssh.socket

On systems without ssh.socket, enable and start the service instead:

sudo systemctl enable --now ssh

On Fedora, RHEL, and derivatives, check and start sshd:

sudo systemctl status sshd
sudo systemctl enable --now sshd

If the unit reports failed, validate the SSH server configuration:

sudo sshd -t

No output means the configuration passed the test. If OpenSSH prints an error, correct the reported line before restarting the unit. You can also inspect the current boot logs on Ubuntu and Debian:

sudo journalctl -u ssh.service -u ssh.socket -b

For Fedora and RHEL, use the sshd unit name:

sudo journalctl -u sshd -b

Install the OpenSSH Server #

Some minimal installations include the SSH client but not the server. If systemctl reports that the SSH unit does not exist, install the openssh-server package.

Ubuntu, Debian, and Derivatives #

Update the package index and install the server package:

sudo apt update
sudo apt install openssh-server

The package normally starts the appropriate SSH service or socket during installation. Check port 22 again with ss instead of assuming that the listener started successfully.

Fedora, RHEL, and Derivatives #

Install the server package, then enable and start sshd:

sudo dnf install openssh-server
sudo systemctl enable --now sshd

Check the Listening Address #

SSH can run normally but listen only on the loopback interface or one private address. In that case, a local connection works while connections to other server addresses are refused.

Review the listenaddress lines from sshd -T. A value such as 127.0.0.1:22 accepts only local IPv4 connections. OpenSSH reads its main configuration from /etc/ssh/sshd_config and may also read files under /etc/ssh/sshd_config.d/.

Before changing Port or ListenAddress, keep console access open and validate the new configuration with sudo sshd -t. On Ubuntu systems using socket activation, the socket must also reload the generated listening configuration. The port-change guide linked above covers the service and socket steps in order.

Check the Firewall #

A firewall is less likely to cause an immediate refusal than a missing listener. Rules that silently drop traffic usually end with Connection timed out, while an explicit REJECT rule can return Connection refused. Check the firewall after confirming the service and port.

If the server uses UFW, list its rules with numbers:

sudo ufw status numbered

Allow the standard OpenSSH profile when SSH uses port 22:

sudo ufw allow OpenSSH

For a custom port, allow the exact TCP port instead:

sudo ufw allow 2222/tcp

On a server using firewalld, first check the services allowed in the active zone:

sudo firewall-cmd --list-services

Add SSH to both the runtime and permanent configurations if it is missing:

sudo firewall-cmd --add-service=ssh
sudo firewall-cmd --permanent --add-service=ssh

For a custom port, use --add-port=2222/tcp in both commands. Our UFW firewall guide explains how to review and manage rules in more detail.

Check Port Forwarding and External Firewalls #

If SSH works from the same machine or local network but fails from the internet, the OpenSSH listener may already be correct. Check that the router or virtualization platform forwards the external port to the server’s current private address and SSH port.

The same issue can occur with a virtual machine, container, load balancer, or cloud firewall. Confirm that public DNS points to the expected system and that each forwarding rule uses the same port you pass to ssh. Cloud firewall rules often drop traffic and cause a timeout, but an edge device that rejects the request or forwards it to the wrong host can produce a refusal.

Troubleshooting #

Connection refused started after an SSH configuration change
Run sudo sshd -t and correct every reported error. On Ubuntu with socket activation, reload systemd and restart ssh.socket after a valid Port or ListenAddress change, then verify the listener with ss before closing console access.

SSH works with localhost but not the server address
Check the effective ListenAddress values and the firewall rules for the external interface. A listener restricted to 127.0.0.1 or ::1 cannot accept remote connections.

IPv4 works but IPv6 is refused
The server may have an AAAA record without an IPv6 listener. Compare ssh -4 and ssh -6, then correct the DNS record or configure SSH to listen on the intended IPv6 address.

Only one client address is refused
A source-specific firewall rule or a tool such as Fail2ban may be rejecting that address. Review the firewall rules and, if Fail2ban is installed, check the SSH jail with sudo fail2ban-client status sshd.

SSH reaches the server but reports Permission denied
The network path and listener are working, and the failure has moved to authentication. Follow the SSH Permission denied (publickey) guide instead.

Conclusion #

Once the port test succeeds, SSH should move on to host-key verification or authentication. Before exposing the restored service to the internet, review our SSH hardening best practices and restrict firewall access where possible.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 800+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page