SSH Connection Refused: Causes and Fixes on Linux

What Does “SSH Connection Refused” Mean?

SSH (Secure Shell) allows administrators to securely access remote Linux systems through an encrypted connection. The OpenSSH server daemon, usually called sshd, listens for incoming connection requests on a configured TCP port, commonly port 22.

When a client reports Connection refused, the connection attempt was actively rejected before SSH authentication could proceed. Common reasons include no service listening on the requested address and port, an SSH daemon that failed to start, or a firewall or network device actively rejecting the connection.

1. Connection Refused vs. Connection Timed Out vs. Permission Denied

These messages are useful clues, not absolute proof of a particular fault. Firewalls, routers, and other network devices can affect the error returned to the client.

2. Common Causes of SSH Connection Refused

3. Start With These Quick Checks

Run these commands from the client computer first. Replace SERVER_IP with the actual IP address or hostname of your Linux server.

ssh -vvv username@SERVER_IP
ssh -p 22 username@SERVER_IP
nc -vz SERVER_IP 22

The verbose SSH output helps identify the destination and port where the attempt fails. The nc command tests TCP connectivity if Netcat is installed. If your server uses a custom SSH port, replace 22 with that port.

If you have console access to the server, such as a VM console, hypervisor console, or cloud serial console, continue with the checks below.

4. Check Whether the SSH Service Is Running

Linux distributions use different systemd service names. Ubuntu and Debian commonly use ssh; Rocky Linux, RHEL, AlmaLinux, and Fedora commonly use sshd.

Ubuntu and Debian

sudo systemctl status ssh
sudo systemctl start ssh
sudo systemctl enable ssh

Rocky Linux, RHEL, AlmaLinux, and Fedora

sudo systemctl status sshd
sudo systemctl start sshd
sudo systemctl enable sshd

Check the service status before starting or enabling it. The start command starts the service now; the enable command configures it to start automatically at boot.

Install the OpenSSH server if it is missing

On Ubuntu or Debian, install the server package if required:

sudo apt update
sudo apt install openssh-server

On Rocky Linux, RHEL, AlmaLinux, or Fedora, use the distribution’s package manager:

sudo dnf install openssh-server

Then start the appropriate service and verify its status again. Package names and service management can vary by distribution and installation profile.

Inspect service logs

# Ubuntu/Debian
sudo journalctl -u ssh.service -b --no-pager -n 100

# RHEL-based systems
sudo journalctl -u sshd.service -b --no-pager -n 100

Look for configuration errors, missing host keys, port-binding failures, or another process already using the configured port.

5. Verify That SSH Is Listening on the Correct Port

A running service does not automatically prove that SSH is listening on the address and port you are trying to reach. Run:

sudo ss -lntp | grep -E 'sshd|:22'

For a default IPv4 listener, output may include 0.0.0.0:22. An IPv6 wildcard listener may appear as [::]:22. A listener bound only to 127.0.0.1:22 is limited to the IPv4 loopback interface and cannot accept normal remote IPv4 connections.

If the server listens on another port, connect using that port:

ssh -p 2222 username@SERVER_IP

Replace 2222 with the actual configured port. Do not assume that port 22 is correct if the server has been customized.

6. Check the Linux Firewall

After confirming that SSH is listening, check whether the host firewall permits incoming TCP traffic to the configured port. Use the firewall manager that is actually active on your system.

Ubuntu and Debian using UFW

sudo ufw status verbose

If the server uses the default SSH port and the rule is missing, allow SSH:

sudo ufw allow 22/tcp
sudo ufw status numbered

If SSH uses a custom port, allow that port instead. For example:

sudo ufw allow 2222/tcp

Do not enable UFW remotely until you have confirmed that the correct SSH access rule is in place and that your current access method will remain available.

Rocky Linux, RHEL, and Fedora using firewalld

sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

If SSH is supposed to be permitted in the active zone, you can allow the predefined SSH service persistently with:

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

If SSH uses a custom port, configure the appropriate port rule instead of assuming that the standard SSH service definition is sufficient. Make changes to the zone attached to the relevant network interface.

Check other firewall layers

Host firewall rules are only one part of the connection path. Network firewalls, router ACLs, VPN policies, cloud security groups, and network security appliances may also control access. Avoid flushing all firewall rules as a troubleshooting shortcut; doing so can expose services or disrupt other connections.

7. Check the SSH Port and Configuration

OpenSSH server settings are commonly stored in /etc/ssh/sshd_config, with additional configuration snippets supported by some distributions. Check for the configured port and listener addresses:

sudo grep -nE '^[[:space:]]*(Port|ListenAddress|AddressFamily)[[:space:]]' /etc/ssh/sshd_config

Also inspect included configuration files if your distribution uses them. The effective configuration may differ from what you expect because of included snippets or settings defined elsewhere.

Validate the configuration

sudo sshd -t

If the command reports an error, correct the configuration before restarting SSH. If it produces no output, the basic syntax check has passed; that does not guarantee that the server can bind the requested port or is reachable through the network.

Review the effective port and listener settings

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

Use the results to compare the effective configuration with the port and address used by your client. If a configuration change is required, back up the relevant file, make the smallest necessary change, validate it, and then reload or restart the appropriate service.

Apply a verified change

On Ubuntu or Debian:

sudo sshd -t && sudo systemctl restart ssh

On Rocky Linux, RHEL, AlmaLinux, or Fedora:

sudo sshd -t && sudo systemctl restart sshd

Some Ubuntu installations use systemd socket activation for SSH. If you have changed the listening port, check whether ssh.socket is active and follow the relevant distribution’s socket-activation procedure; restarting only the service may not apply the change as expected.

8. Check Fail2ban and Source-IP Blocks

If SSH works from other networks but fails from one client IP, inspect source-specific firewall rules and security tools. Fail2ban can temporarily block IP addresses after repeated failed login attempts, depending on the jail and firewall action configured on the server.

Check whether Fail2ban is running:

sudo systemctl status fail2ban

If it is installed and running, inspect the SSH jail:

sudo fail2ban-client status
sudo fail2ban-client status sshd

If your address appears in the jail’s banned list, verify that it is genuinely your trusted client address before unbanning it. The following example removes a specific address from the SSH jail:

sudo fail2ban-client set sshd unbanip YOUR_CLIENT_IP

Replace YOUR_CLIENT_IP with the exact address you have confirmed. Do not disable Fail2ban entirely or remove security protections without identifying the cause of the block.

9. Check Networking, NAT, Virtual Machines, and Cloud Firewalls

If the SSH service and local listener are correct, test the connection path between the client and server. This is especially important for virtual machines, nested virtualization labs, cloud instances, and servers behind a router.

Confirm the destination address

getent hosts your-server.example.com

Confirm that the resolved IP address is the intended server. If the server has multiple network interfaces, verify the address assigned to the interface reachable from your client.

Test the port from the client

On Linux, if Netcat is installed:

nc -vz SERVER_IP 22

On Windows PowerShell:

Test-NetConnection -ComputerName SERVER_IP -Port 22

Replace port 22 if the server uses another port. A failed test does not, by itself, identify which firewall or network device is responsible.

Check NAT and port forwarding

For a server behind a router or virtualized network, verify all of the following:

• The forwarding rule targets the server’s current private IP address.
• The external port maps to the correct internal SSH port.
• The server’s firewall allows the forwarded connection.
• The public DNS record points to the correct public endpoint.
• The client is testing the correct address from the intended network.

Check cloud networking

For a cloud VM, review the cloud firewall or security-group rules, network ACLs, route tables, and any private-network or bastion requirements. Permit SSH only from trusted source addresses where practical rather than opening management access to the entire internet.

Compare IPv4 and IPv6

A hostname can resolve to both IPv4 and IPv6 addresses, but the SSH server may only listen on one address family. Compare the connection attempts:

ssh -4 username@your-server.example.com
ssh -6 username@your-server.example.com

If only one works, check the DNS records, listener configuration, routing, and firewall rules for the failing address family.

10. Troubleshooting by Symptom

11. Prevent Future SSH Connection Problems

• Monitor the SSH service: Review service status and logs after updates or configuration changes.
• Validate before restarting: Run sudo sshd -t after editing server configuration.
• Document the SSH port: Record the configured port and use it consistently in firewall rules, NAT mappings, and client commands.
• Keep a recovery path: Maintain hypervisor, cloud console, or other out-of-band access for critical servers.
• Use key-based authentication: After verifying that key-based login works, consider disabling password authentication according to your access and recovery requirements.
• Restrict administrative access: Limit SSH access to trusted networks or source IPs where possible.
• Use layered protection: Apply security updates, least-privilege access, firewall rules, monitoring, and tools such as Fail2ban where appropriate.

For a step-by-step security baseline, read our guide: Harden SSH on Linux by Disabling Root and Password Login. If you need automated blocking of repeated authentication failures, see Fail2ban for SSH: Installation and Configuration.

Conclusion

The most reliable way to fix SSH connection refused is to work from the service outward: verify that OpenSSH is installed and running, confirm the correct listening address and port, validate the configuration, inspect host and network firewalls, and check for source-IP blocks.

Once connectivity is restored, strengthen the server with key-based authentication, least-privilege access, and appropriate monitoring. Continue with the VMoreCloud guides on SSH hardening and Fail2ban protection for the next steps.

Sources and Further Reading

• Ubuntu Server Documentation — OpenSSH Server
• Ubuntu Server Documentation — Firewall
• Linuxize — SSH Connection Refused: Causes and Fixes
• Microsoft Learn — Troubleshoot OpenSSH Communication Through Windows Firewall

Commands and service names can differ by Linux distribution, OpenSSH version, and systemd configuration. Always verify your environment before applying changes to a remote production server.