How to Fix SSH Connection Refused on Ubuntu (Including 24.04 LTS)

“Connection refused” is the most common SSH error on Ubuntu systems, and it almost always means one of three things: the SSH server isn’t installed, it isn’t running, or something is blocking port 22. This guide walks through every likely cause, from a missing openssh-server package to firewall rules and SELinux-like restrictions, with verification steps at each stage.

Quick Diagnosis

Run this from the machine you’re trying to connect to (the Ubuntu host):

sudo systemctl status ssh

If you cannot access the machine locally or through a console, work through each section in order.

Prerequisites

• Local or console access to the Ubuntu machine (physical terminal, virtual console, or cloud provider’s web console).
• A user account with sudo privileges.
• A working network connection between client and server.

These instructions apply to Ubuntu 22.04 LTS, 24.04 LTS (including 24.04.1), and Ubuntu Server editions. The relevant commands are identical across desktop and server variants.

Install OpenSSH Server

Ubuntu desktop installations do not include the SSH server by default. Ubuntu Server includes it only if you selected “OpenSSH server” during installation. If the package is missing, any connection attempt returns “Connection refused” because nothing is listening on port 22.

Verify Whether OpenSSH Server Is Installed

dpkg -l openssh-server 2>/dev/null | grep -q '^ii' && echo "Installed" || echo "Not installed"

If the output is Not installed, proceed with installation.

Install the Package

sudo apt update
sudo apt install openssh-server -y

On Ubuntu 24.04, this installs OpenSSH 9.6p1 (or later point release) and automatically enables and starts the ssh.service unit.

Verify Installation Succeeded

sudo systemctl status ssh

Expected output includes active (running). If it shows anything else, continue to the next section.

Note on “command not found”: If running ssh (the client) gives “command not found,” the client package is also missing. Install it with sudo apt install openssh-client. This is separate from the server — the client lets you connect from this machine, while openssh-server lets others connect to it.

Start and Enable the SSH Service

If openssh-server is installed but the service isn’t running, connections will be refused.

Start the Service

sudo systemctl start ssh

Enable It to Start on Boot

sudo systemctl enable ssh

Check the Service Status

sudo systemctl status ssh

If the status shows failed, examine the journal for the actual error:

sudo journalctl -xeu ssh --no-pager | tail -40

Common failure causes:

• Bad configuration syntax — a typo in /etc/ssh/sshd_config prevents sshd from starting. Validate the config: sudo sshd -tThis prints any syntax errors with line numbers. Fix them, then restart: sudo systemctl restart ssh
• Port conflict — another process is already bound to port 22. Check with: sudo ss -tlnp | grep ':22'
• Missing host keys — regenerate them if the journal mentions missing key files: sudo ssh-keygen -A sudo systemctl restart ssh

Ubuntu 24.04 Socket-Activated SSH

Ubuntu 22.10 and later (including 24.04) use systemd socket activation by default. The actual units are ssh.socket and ssh.service. With socket activation, ssh.service may appear inactive until a connection arrives — this is normal.

Check the socket:

sudo systemctl status ssh.socket

If ssh.socket is active (listening), SSH is ready to accept connections even if ssh.service shows inactive. If you prefer the traditional always-running daemon, disable the socket and enable the service directly:

sudo systemctl disable --now ssh.socket
sudo systemctl enable --now ssh.service

Check the Firewall

Ubuntu ships with ufw (Uncomplicated Firewall), which is inactive by default. If someone has enabled it without allowing SSH, connections on port 22 are silently dropped or refused.

Check UFW Status

sudo ufw status

If it shows Status: active and there’s no rule for port 22 or “OpenSSH,” add one:

sudo ufw allow ssh

This opens TCP port 22. If you’ve configured sshd to listen on a non-standard port (e.g., 2222):

sudo ufw allow 2222/tcp

Reload and verify:

sudo ufw reload
sudo ufw status verbose

Check iptables/nftables Directly

If UFW isn’t in use, raw iptables or nftables rules may still block traffic:

sudo iptables -L INPUT -n --line-numbers | grep -E 'dpt:22|DROP|REJECT'

For nftables (default backend on Ubuntu 24.04):

sudo nft list ruleset | grep -A2 'dport 22'

If a DROP or REJECT rule targets port 22, remove or modify it. For example, to delete iptables rule number 3 in the INPUT chain:

sudo iptables -D INPUT 3

Cloud Provider Security Groups

If your Ubuntu machine runs on AWS, GCP, Azure, or another cloud platform, a “Connection refused” or timeout can originate from the cloud-level firewall (security groups, firewall rules, or NSGs), not the OS. Verify that inbound TCP port 22 is allowed in the provider’s console. These rules take effect outside the VM and cannot be diagnosed from inside it.

Verify SSH Is Listening on the Correct Port and Address

Confirm that sshd is bound to the expected port and address:

sudo ss -tlnp | grep sshd

Expected output for a default configuration:

LISTEN  0  128  0.0.0.0:22  0.0.0.0:*  users:(("sshd",pid=1234,fd=3))
LISTEN  0  128     [::]:22     [::]:*  users:(("sshd",pid=1234,fd=4))

If the output is empty, sshd is not listening — revisit the service status. If it shows a different port (e.g., 2222), either connect to that port:

ssh -p 2222 user@host

or change the port back to 22 in /etc/ssh/sshd_config:

sudo grep -i '^Port' /etc/ssh/sshd_config

If the ListenAddress directive restricts sshd to a specific IP (e.g., 127.0.0.1), remote connections are refused. Set it to 0.0.0.0 to listen on all IPv4 addresses, or comment it out to use the default (all interfaces):

sudo nano /etc/ssh/sshd_config

After changes, validate and restart:

sudo sshd -t && sudo systemctl restart ssh

Fix “Permission Denied” Alongside Connection Refused

“Permission denied” is a different error from “Connection refused” — it means SSH connected successfully but authentication failed. If you see both errors in sequence after fixing the connection, check these settings:

Password Authentication

Verify it’s enabled (if you intend to use passwords):

sudo grep -i '^PasswordAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null

On Ubuntu 24.04, drop-in files in /etc/ssh/sshd_config.d/ override the main config. A file like 50-cloud-init.conf may set PasswordAuthentication no. To enable it:

echo "PasswordAuthentication yes" | sudo tee /etc/ssh/sshd_config.d/60-allow-password.conf
sudo sshd -t && sudo systemctl restart ssh

Security note: Password authentication is less secure than key-based authentication, especially on internet-facing servers. Prefer SSH keys and disable password auth once keys are configured.

Root Login

By default, PermitRootLogin is set to prohibit-password on Ubuntu, meaning root can authenticate only with keys, not passwords. If you need root access via SSH (generally discouraged), change it to yes — but understand the security trade-off.

Key Permissions

If using key-based authentication, OpenSSH is strict about file permissions:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

On the client side, the private key must also be restricted:

chmod 600 ~/.ssh/id_rsa

Locked or Expired Account

A locked user account causes “Permission denied” regardless of valid credentials:

sudo passwd -S username

If the status shows L (locked), unlock it:

sudo passwd -u username

Test Connectivity Step by Step

Work through these checks from the client machine to isolate where the connection fails:

1. Verify Network Reachability

ping -c 3 server_ip

If ping fails, you have a network-level issue (routing, DNS, or the server is down) unrelated to SSH.

2. Test the TCP Port

nc -zv server_ip 22

• Connection refused → nothing is listening on port 22, or a firewall is sending a TCP RST.
• Connection timed out → a firewall is dropping packets silently.
• Connection succeeded → the SSH daemon is reachable; the problem is in authentication or the SSH handshake.

3. Attempt SSH with Verbose Output

ssh -vvv user@server_ip

The triple-verbose flag shows the full handshake, key exchange, and authentication stages. Look for the line where the connection fails.

Common Causes Summary

Security Best Practices

Once SSH is working, harden the configuration:

• Use SSH keys instead of passwords. Generate a key pair with ssh-keygen -t ed25519 and copy the public key with ssh-copy-id user@server.
• Disable password authentication after confirming key-based login works.
• Disable root login (PermitRootLogin no) and use sudo instead.
• Install fail2ban to block brute-force attempts: sudo apt install fail2ban -y
• Keep OpenSSH updated — security patches arrive through standard apt upgrade.
• Consider a non-standard port only as a minor obscurity measure; it does not replace real security controls.

Conclusion

“Connection refused” on Ubuntu almost always traces back to a missing or stopped SSH server, or a firewall blocking port 22. Start by confirming openssh-server is installed and ssh.service (or ssh.socket on Ubuntu 24.04) is active, then check UFW and any cloud-level firewall rules. Use ss -tlnp to verify what port sshd is actually listening on, and ssh -vvv from the client to pinpoint where the connection fails. Once resolved, take a few minutes to configure key-based authentication and basic hardening — it prevents the majority of SSH-related security incidents.