Fix "ssh: connect to host ... port 22: Connection refused"

# Ubuntu / Debian / Mint
sudo apt install openssh-server
sudo systemctl enable --now ssh
# Fedora / Arch / openSUSE
sudo systemctl enable --now sshd
# check what is listening
sudo ss -tlnp | grep -E ':22\b|ssh'

The exact error (host and port vary):

ssh: connect to host 192.168.1.20 port 22: Connection refused

What the error means

Your client reached the machine at that address, and the machine replied with a TCP reset (or an ICMP "port unreachable" from a firewall). In other words, the network path works but nothing accepts connections on that port. That points to the server side: SSH not installed, not running, listening on another port or address, or a firewall rule that rejects.

Compare with the related messages, because each points somewhere different:

Cause 1: no SSH server installed

Desktop installs of Ubuntu, Mint, Fedora Workstation and most others include only the SSH client. Server images usually include the server; desktops do not.

# Ubuntu, Debian, Mint
sudo apt install openssh-server
# Fedora
sudo dnf install openssh-server
# Arch
sudo pacman -S openssh
# openSUSE
sudo zypper install openssh-server

Cause 2: the service is not running

The unit name differs by distro: ssh on Debian, Ubuntu and Mint; sshd on Fedora, Arch and openSUSE. Arch and openSUSE do not enable it after installation.

systemctl status ssh      # Debian family
systemctl status sshd     # Fedora, Arch, openSUSE
sudo systemctl enable --now sshd

If it fails to start, the log tells you why (often a typo in the config):

sudo sshd -t              # test config syntax
sudo journalctl -u ssh -b  # or -u sshd

If the service fails, the Job for service failed page walks through reading the error. A port already taken by another program gives Address already in use in that log.

Ubuntu 22.10 and later: ssh.socket

On current Ubuntu releases, systemd's ssh.socket listens on the port and starts ssh.service on the first connection. So ssh.service showing inactive is normal; what matters is the socket:

systemctl status ssh.socket
sudo systemctl enable --now ssh.socket

If you disabled ssh.service and the socket, nothing listens and you get Connection refused.

Cause 3: wrong port or listen address

If the server's Port is not 22, you must say so on the client:

ssh -p 2222 [email protected]

Check what the server actually listens on:

sudo ss -tlnp | grep ssh

Example output:

LISTEN 0  4096  127.0.0.1:22  0.0.0.0:*  users:(("sshd",pid=812,fd=3))

Here sshd listens only on 127.0.0.1, so remote connections are refused. Look for a ListenAddress line in /etc/ssh/sshd_config and files under /etc/ssh/sshd_config.d/.

Changing the port on Ubuntu with socket activation

On Ubuntu 24.04 and later, a systemd generator reads Port and ListenAddress from the sshd config and applies them to ssh.socket, but only after a reload:

echo 'Port 2222' | sudo tee /etc/ssh/sshd_config.d/10-port.conf
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

Restarting only ssh.service leaves the socket on the old port. On Ubuntu 22.10 to 23.10 the generator did not exist; you had to override ListenStream in a drop-in for ssh.socket (or disable the socket and enable ssh.service). Keep your current session open until a login on the new port works.

Fedora and SELinux

On Fedora (and openSUSE Leap 16 with SELinux), sshd may not bind to a non-standard port until SELinux allows it:

sudo semanage port -a -t ssh_port_t -p tcp 2222
sudo systemctl restart sshd

Cause 4: a firewall rejects the port

A firewall that rejects produces "refused"; one that drops produces "timed out". Open SSH on the server's firewall:

# Ubuntu / Mint with ufw
sudo ufw allow OpenSSH        # or: sudo ufw allow 2222/tcp
# Fedora / openSUSE with firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-port=2222/tcp   # custom port
sudo firewall-cmd --reload

Also check fail2ban or sshguard: after repeated failed logins they block your IP, which can show up as refused or timed out. sudo fail2ban-client status sshd lists banned addresses. Cloud security groups, router port forwarding and VM NAT (VirtualBox, libvirt) are other places the port can be closed: with NAT you must forward a host port to guest port 22 and connect to the host's forwarded port.

Cause 5: you are reaching a different machine

An outdated IP from DHCP, a wrong DNS record, or a container/VM IP that changed can send you to a host that simply has no SSH server. Confirm the address on the server with ip -brief addr and test the port from the client:

nc -zv 192.168.1.20 22

Still not working?

Test from the server itself: ssh localhost. If that works, sshd is fine and the problem is the address, port or firewall between you. If it fails too, the problem is sshd. Then run the client verbosely, ssh -vvv -p PORT user@host, to see exactly where it stops. Once you connect, the next typical hurdle is Permission denied (publickey). The Linux networking basics guide covers ss, ip and firewalls in more depth, and the systemctl cheat sheet covers service management.

How to prevent it

• Enable the service (or socket) at boot, not just start it.
• When changing ports, open the new port in the firewall first, keep a session open, and test before closing.
• Put custom settings in /etc/ssh/sshd_config.d/*.conf and run sudo sshd -t before restarting.
• Give servers a static IP or DHCP reservation.

Frequently asked questions