SSH Connection Refused: Causes and Fixes

Linux Troubleshooting Guide

SSH Connection Refused: Causes and Fixes

Learn how to diagnose and fix SSH connection refused errors on Linux servers. Follow practical steps to check the SSH service, listening ports, firewall rules, cloud security groups, configuration files, access restrictions, and hostname resolution.

Linux OpenSSH System Administration Intermediate

Secure Shell (SSH) is one of the most common tools for administering Linux servers, managing cloud virtual machines, deploying applications, and automating infrastructure tasks. When SSH stops working, remote administration can quickly become difficult.

One common error is “Connection refused.” It often appears when a client tries to connect to a Linux server on TCP port 22 but no SSH service is accepting the connection, or a network device actively rejects it.

The important point is that this error does not automatically mean your username or password is incorrect. Authentication usually happens after the SSH connection has been established. The first task is to find out whether the server is reachable and whether an SSH service is listening on the expected address and port.

Quick fix: If you have console access to the server, check the SSH service and listening port first. On Ubuntu or Debian, the service is usually named ssh. On RHEL, Rocky Linux, AlmaLinux, and Fedora, it is commonly named sshd.

1. What Does SSH Connection Refused Mean?

When you run a command such as:

ssh admin@192.168.1.50

the SSH client normally attempts to establish a TCP connection to the destination server on port 22. If that connection is actively rejected, the client may display an error similar to:

ssh: connect to host 192.168.1.50 port 22: Connection refused

Common explanations include:

The SSH server is stopped or failed to start.
Nothing is listening on the destination port.
The server is configured to use a different SSH port.
A firewall or network security device is actively rejecting the connection.
The client is connecting to the wrong IP address or hostname.
The SSH daemon is listening only on another network interface.

Start by confirming the destination address and port, then investigate the server-side service. If you cannot access the server through SSH, use its local console, hypervisor console, serial console, or cloud-provider management console.

2. Connection Refused vs Connection Timed Out vs Permission Denied

These messages indicate different stages of a connection attempt. Identifying the correct one prevents you from troubleshooting the wrong layer.

Error	What it usually means	Where to start
Connection refused	The TCP connection was rejected, commonly because no service is listening on that port or a device actively rejected it.	SSH service, listening port, address, and firewall reject rules.
Connection timed out	No usable response arrived before the connection attempt timed out.	Routing, VPN, network ACLs, firewall drops, cloud security groups, and reachability.
Permission denied	The SSH server was reached, but authentication or an account access policy rejected the login.	Username, SSH keys, password policy, account status, and server authentication logs.

These are typical patterns, not absolute rules. Firewalls and intermediate network devices can change how errors appear. For example, a firewall configured to reject traffic can cause “Connection refused,” while a firewall that silently drops packets commonly produces a timeout.

3. Cause: The SSH Daemon Is Not Running

Diagnosis

The OpenSSH server process may be stopped, disabled, or unable to start after a configuration change, package update, or system reboot.

Check the service on Ubuntu or Debian:

sudo systemctl status ssh

Check the service on RHEL, Rocky Linux, AlmaLinux, or Fedora:

sudo systemctl status sshd

Review the service logs if the status shows failed or the service is inactive:

sudo journalctl -u ssh -b --no-pager
sudo journalctl -u sshd -b --no-pager

Fix

Start the appropriate service. Run the command that matches your distribution:

# Ubuntu / Debian
sudo systemctl start ssh
sudo systemctl enable ssh

# RHEL / Rocky Linux / AlmaLinux / Fedora
sudo systemctl start sshd
sudo systemctl enable sshd

Verify the service again:

sudo systemctl status ssh
# Or, on distributions using sshd:
sudo systemctl status sshd

If the service fails again, inspect its logs and validate the configuration before repeatedly restarting it.

4. Cause: A Firewall or Cloud Security Group Blocks SSH

Diagnosis

A host firewall, network firewall, cloud security group, or network access control list may block the SSH port. A firewall can either drop traffic or actively reject it.

On Ubuntu systems using UFW, check the rules:

sudo ufw status verbose

On systems using firewalld:

sudo firewall-cmd --state
sudo firewall-cmd --list-all

To inspect nftables rules:

sudo nft list ruleset

From the client, test the destination port if a suitable network utility is installed:

nc -vz 192.168.1.50 22

Fix

If UFW is blocking SSH and the server is intended to accept SSH connections, permit the service:

sudo ufw allow OpenSSH
sudo ufw status verbose

Alternatively, allow a specific TCP port if the server uses a custom port:

sudo ufw allow 2222/tcp

For firewalld, add the SSH service to the active zone:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

If SSH uses a custom port, add that TCP port instead, then verify the active zone and rules.

Security note: Do not open SSH to every IP address unless your environment requires it. Prefer allowing a trusted administration IP or VPN subnet. Before changing firewall rules on a remote system, confirm that you have an alternative management path so you do not lock yourself out.

Check cloud firewall rules too

For a cloud VM, verify that the relevant network controls allow inbound TCP traffic to the configured SSH port:

AWS: Check the EC2 security group inbound rules, network ACLs, subnet route table, and instance network configuration.
Microsoft Azure: Check the network security group (NSG), effective security rules, subnet configuration, and route table.
Google Cloud: Check the VPC firewall rules, network tags or service accounts, and applicable routes.

A Linux firewall change alone will not fix a connection blocked by a cloud network rule.

5. Cause: SSH Is Listening on a Different Port

Diagnosis

SSH normally uses TCP port 22, but administrators can configure a different port in /etc/ssh/sshd_config. If the server listens on port 2222 while the client connects to port 22, the default connection may be refused.

Check the listening sockets on the server:

sudo ss -tlnp | grep -E 'ssh|:22|:2222'

Review active SSH port settings in the main configuration and any included files:

sudo grep -RniE '^[[:space:]]*Port[[:space:]]' /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

Fix

If the server listens on port 2222, connect using the -p option:

ssh -p 2222 admin@192.168.1.50

For a nonstandard port, ensure the host firewall and cloud security rules allow that port. If you intend to use port 22, correct the SSH configuration and restart the service after validating it.

Remember that the lowercase -p option specifies the port for the SSH client. The uppercase -p option has a different meaning in other SSH commands, such as scp.

6. Cause: Incorrect sshd_config Settings

Diagnosis

The SSH daemon reads its server configuration from /etc/ssh/sshd_config and may also load files from an included configuration directory. An invalid directive, conflicting setting, or incorrect address binding can prevent the daemon from starting or listening where expected.

Validate the SSH server configuration:

sudo sshd -t

If the command returns an error, inspect the reported file and line. Check relevant settings:

sudo grep -RniE '^[[:space:]]*(Port|ListenAddress|AllowUsers|DenyUsers|AllowGroups|DenyGroups|Include)[[:space:]]' /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

Fix

Back up the configuration before making changes:

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Open the configuration using your preferred editor:

sudo nano /etc/ssh/sshd_config

For example, a basic configuration might include:

Port 22
ListenAddress 0.0.0.0
ListenAddress ::

These address settings request listening on all IPv4 and IPv6 addresses, respectively, where supported. You can instead specify a particular server address if SSH should only be available on a management interface. Do not add duplicate or conflicting directives without understanding OpenSSH configuration precedence and included files.

Validate the configuration again:

sudo sshd -t

If validation succeeds, reload the service where supported:

# Ubuntu / Debian
sudo systemctl reload ssh

# RHEL-family distributions
sudo systemctl reload sshd

If reload is unsupported or the service is not running, follow the distribution’s service-management procedure and check the logs. Keep an existing administrative session open while testing a new connection.

7. Cause: AllowUsers, DenyUsers, or Host-Based Access Restrictions

OpenSSH supports account and group restrictions through directives such as AllowUsers, DenyUsers, AllowGroups, and DenyGroups. These settings normally reject a login after the client has connected to the SSH server. Therefore, they are more commonly associated with authentication or access-denied errors than with a TCP-level “Connection refused” message.

Diagnosis

Search the server configuration for access restrictions:

sudo grep -RniE '^[[:space:]]*(AllowUsers|DenyUsers|AllowGroups|DenyGroups)[[:space:]]' /etc/ssh/sshd_config /etc/ssh/sshd_config.d 2>/dev/null

Review the server logs while reproducing the failed login:

sudo journalctl -u ssh -f
# Or:
sudo journalctl -u sshd -f

Some older Linux environments use TCP Wrappers files such as /etc/hosts.allow and /etc/hosts.deny. Check whether the installed SSH build or another access-control layer actually uses them:

sudo cat /etc/hosts.allow
sudo cat /etc/hosts.deny

Fix

If the intended account is excluded by an SSH access directive, adjust the rule according to your access policy. For example:

AllowUsers admin deploy

This example permits only the listed usernames, subject to the remaining SSH policies. It is not a universal configuration to copy without review. Test the intended account and validate the configuration before reloading SSH.

Do not assume that editing hosts.allow or hosts.deny will fix a modern Linux server. TCP Wrappers support is absent from many current OpenSSH packages, so verify whether those files are relevant to your installation.

8. Cause: The Wrong IP Address or Hostname

Diagnosis

The hostname may resolve to an outdated address, a private IP may be used from outside its network, or a cloud VM’s public IP may have changed. You may also be connecting to a different machine that does not run SSH.

Resolve the hostname on the client:

getent hosts server.example.com

On systems with DNS tools installed, you can also run:

nslookup server.example.com

Check the destination and route:

ip route get 192.168.1.50

Fix

Verify the server’s current IP address in its console, DHCP lease, DNS record, inventory, or cloud management portal. Then connect directly to the confirmed address:

ssh admin@192.168.1.50

If the IP works but the hostname does not, correct the relevant DNS record or local name-resolution entry. If the server has only a private IP, connect through the appropriate VPN, private network, bastion host, or jump server rather than assuming the address is reachable over the public internet.

9. Cause: OpenSSH Server Is Not Installed

Diagnosis

A minimal Linux installation or newly created VM may not have the OpenSSH server package installed. An SSH client can be present even when the machine cannot accept incoming SSH connections.

Check whether the server binary exists:

command -v sshd

Fix

Install the server package if it is missing and SSH access is required.

# Ubuntu / Debian
sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now ssh

# RHEL / Rocky Linux / AlmaLinux / Fedora
sudo dnf install openssh-server
sudo systemctl enable --now sshd

After installation, confirm the service is active and listening:

sudo systemctl status ssh
sudo ss -tlnp | grep ssh

On RHEL-family systems, substitute sshd in the service-status command. If the package is installed but the service fails to start, investigate its configuration and logs.

10. Cause: SSH Is Listening on the Wrong Network Interface

Diagnosis

The SSH service might be running but bound only to the loopback address, a private interface, or an IP address that is not reachable from your client.

Inspect the listening sockets:

sudo ss -tlnp | grep ssh

Examples of how to interpret the output:

127.0.0.1:22 — listening only on the IPv4 loopback interface.
192.168.1.50:22 — listening on that specific IPv4 address.
0.0.0.0:22 — listening on all local IPv4 interfaces.
[::]:22 — listening on the IPv6 wildcard address; actual IPv4 behavior depends on system configuration.

Fix

Confirm the server’s interface addresses:

ip -br address

If the listener is bound to the wrong address, correct the relevant ListenAddress setting in /etc/ssh/sshd_config or its included files. Validate the configuration with sudo sshd -t, then reload the service where supported.

Also verify that the destination address belongs to this server and that the relevant route and firewall rules permit the incoming connection.

11. Diagnose the Error with Logs and Verbose SSH Output

If the cause is still unclear, collect evidence from both the client and the server. The client’s verbose output helps identify where the attempt fails, while server logs reveal service startup problems and authentication restrictions.

Run SSH in verbose mode

From the client, run:

ssh -vvv admin@192.168.1.50

For a custom port:

ssh -vvv -p 2222 admin@192.168.1.50

Look for the last messages before the error. If the output stops at an attempt to connect to the host and port, investigate reachability, the listening socket, and firewall rules. If the server responds and the output progresses to authentication, focus on keys, credentials, account restrictions, and authentication logs.

Check the server’s SSH logs

On Ubuntu and Debian:

sudo journalctl -u ssh -b --no-pager
sudo tail -n 100 /var/log/auth.log

On RHEL-family systems:

sudo journalctl -u sshd -b --no-pager
sudo tail -n 100 /var/log/secure

Log-file paths can vary by distribution and logging configuration. Use the journal if the traditional log file does not exist.

Confirm that the port is reachable

From the client, use a TCP test when Netcat is available:

nc -vz 192.168.1.50 22

You can also use a Bash TCP test on systems where Bash supports /dev/tcp:

timeout 3 bash -c 'echo > /dev/tcp/192.168.1.50/22'

These tests help determine whether a TCP connection can be established, but they do not prove that SSH authentication will succeed. Interpret the result alongside the server’s listening sockets, logs, and network rules.

Important: If the SSH daemon is not receiving the connection at all, server authentication logs may contain no corresponding entry. In that case, investigate the listener, destination IP, routing, and network filtering before changing passwords or SSH keys.

12. Final Troubleshooting Checklist

Follow this order when you encounter an SSH connection refused error. It helps isolate the problem without making unnecessary configuration changes.

Confirm the destination: Verify the hostname, IP address, and SSH port.
Check the SSH service: Run systemctl status ssh on Ubuntu/Debian or systemctl status sshd on RHEL-family systems.
Inspect the listener: Run sudo ss -tlnp | grep ssh on the server.
Verify the port: Check the active SSH configuration and connect with ssh -p PORT user@host if necessary.
Validate configuration: Run sudo sshd -t before reloading or restarting the service.
Check host firewalls: Inspect UFW, firewalld, nftables, or the firewall used by your distribution.
Check cloud networking: Verify security groups, NSGs, network ACLs, routes, and VPN connectivity.
Review logs: Use journalctl -u ssh or journalctl -u sshd, depending on the distribution.
Run client diagnostics: Execute ssh -vvv user@host to see where the connection attempt fails.
Test again safely: Keep an existing session or console available until the new SSH connection works.

Conclusion

The SSH “Connection refused” error usually points to a connection-level problem: the SSH daemon is not listening, the client is using the wrong port or address, or a firewall or network device is rejecting the connection. Begin by checking the service and listening socket, then work outward through the host firewall, cloud networking, and configuration.

Do not confuse this error with “Connection timed out” or “Permission denied.” A timeout generally directs attention toward network reachability and dropped traffic, while a permission error means the connection reached the SSH server but access was not granted. That distinction makes troubleshooting faster and more accurate.

References and Official Documentation

OpenBSD: sshd manual — SSH daemon behavior and options.
OpenBSD: sshd_config manual — server configuration directives.
OpenBSD: ssh manual — SSH client options, including verbose mode and port selection.
Ubuntu Server documentation: OpenSSH server — installing and configuring SSH on Ubuntu.
Red Hat documentation — consult the documentation for your RHEL version and its firewall and SSH configuration.

About the Author

Khurram Shahzad — Hybrid Cloud & Virtualization Engineer

Hybrid Cloud & Virtualization Engineer specializing in VMware, Azure, AWS, Windows Server, Microsoft 365, Linux, networking, backup & disaster recovery. I share practical guides, technical projects and insights into modern IT infrastructure through VMoreCloud.

Explore more Linux guides on VMoreCloud

Disclaimer: Commands and configuration examples are provided for educational purposes. Verify the distribution, service name, active configuration, and security policy in your environment before applying changes to production systems.