Linux SSH Connection Refused: 5 Critical Fixes That Actually Work

Updated 2026-08-15

SSH “Connection Refused” means the server either:

1. Isn’t listening on port 22 (daemon crashed, disabled, or wrong port)
2. Firewall is blocking the connection (UFW, iptables, cloud provider rules)
3. Network routing is broken (routing table, NAT misconfiguration)

99% resolved by: Verifying SSH daemon is running (sudo systemctl status ssh), checking firewall (sudo ufw status), and testing connectivity (telnet <host> 22).

Diagnosis Checklist (Fastest Path)

Run these commands on the server to isolate the problem:

# 1. Is SSH daemon running?
sudo systemctl status ssh

# 2. Is it listening on port 22?
sudo ss -tlnp | grep ssh

# 3. Is firewall blocking?
sudo ufw status numbered

# 4. Are key permissions wrong?
ls -la ~/.ssh/authorized_keys

# 5. Is SELinux blocking? (RHEL/CentOS/Fedora only)
getenforce

Fix 1: SSH Daemon Not Running

Symptom

ssh user@server
Connection refused

BUT locally on the server:

sudo systemctl status ssh
● ssh.service - OpenSSH server daemon
     Loaded: loaded (/lib/systemd/system/ssh.service; disabled)
     Active: inactive (dead)

Root Cause

OpenSSH daemon (sshd) is stopped or disabled.

Fix

On Ubuntu/Debian

# Start immediately
sudo systemctl start ssh

# Enable on boot
sudo systemctl enable ssh

# Verify it's listening
sudo ss -tlnp | grep ssh
tcp    LISTEN     0      128                 0.0.0.0:22                0.0.0.0:*     users:(("sshd",pid=5432,fd=3))

On RHEL/CentOS/Fedora

sudo systemctl start sshd
sudo systemctl enable sshd

Fix 2: Firewall Blocking SSH

Symptom

telnet server.local 22
Trying server.local...
telnet: Unable to connect to remote host: Connection refused

Root Cause

UFW (Uncomplicated Firewall) is blocking port 22.

Check Current Rules

sudo ufw status numbered

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     DENY        Anywhere
[ 2] 80/tcp                     ALLOW       Anywhere
[ 3] 443/tcp                    ALLOW       Anywhere

If SSH shows DENY, it’s the issue.

Fix: Allow SSH

# Allow SSH from any IP
sudo ufw allow 22/tcp

# Or restrict to specific subnet (recommended)
sudo ufw allow from 192.168.1.0/24 to any port 22

# Reload and verify
sudo ufw reload
sudo ufw status

AWS/Azure/GCP Security Groups/Network ACLs

If running on cloud, check the instance’s inbound rules:

• AWS EC2: Security Group must have rule: Type: SSH, Port: 22, Source: 0.0.0.0/0 (or restricted CIDR)
• Azure NSG: Inbound rule for Destination Port: 22
• GCP Firewall: Tag-based rule with tcp:22 priority ≤ 1000

Fix 3: SSH Listening on Different Port

Symptom

You’ve configured SSH on port 2222 (common for hardening), but trying to connect on port 22.

Verify Port Configuration

sudo cat /etc/ssh/sshd_config | grep -E "^Port"

Port 2222

Connect to Correct Port

ssh -p 2222 user@server
# or
ssh user@server -o Port=2222

Update Local SSH Config

# ~/.ssh/config
Host myserver
    HostName server.local
    Port 2222
    User ubuntu

# Then just use:
ssh myserver

Fix 4: Key Permission Issues

Symptom

Permission denied (publickey).

Root Cause

authorized_keys file or .ssh/ directory has wrong permissions.

Check Permissions

ls -la ~/.ssh/

total 12
drwx------  2 ubuntu ubuntu 4096 Aug 15 10:42 .
-rw-------  1 ubuntu ubuntu  400 Aug 15 10:42 authorized_keys
-rw-------  1 ubuntu ubuntu 1679 Aug 15 10:40 id_rsa
-rw-r--r--  1 ubuntu ubuntu  401 Aug 15 10:40 id_rsa.pub

Correct Permissions

• .ssh/ → drwx------ (700)
• authorized_keys → -rw------- (600)
• id_rsa → -rw------- (600)
• id_rsa.pub → -rw-r--r-- (644)

Fix Permissions

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

Verify Keys Are Loaded

# On client
ssh-add -l
2048 SHA256:xyz123... ~/.ssh/id_rsa (RSA)

# If empty, load the key:
ssh-add ~/.ssh/id_rsa

Fix 5: SELinux or AppArmor Blocking

For RHEL/CentOS/Fedora (SELinux)

# Check SELinux status
getenforce
Enforcing

# Check SSH context
sudo ls -laZ /var/lib/sshd/

# Fix: Set correct context
sudo restorecon -Rv /var/lib/sshd/
sudo restorecon -Rv /etc/ssh/

# Restart SSH
sudo systemctl restart ssh

For Ubuntu (AppArmor)

# Check profile
sudo aa-status | grep ssh

# If SSH is in complain mode, switch to enforce
sudo aa-enforce /etc/apparmor.d/usr.sbin.sshd

# Restart
sudo systemctl restart ssh

Advanced Diagnostics

Enable SSH Debug Logging (Client Side)

ssh -vvv user@server

Look for lines like:

debug1: Connecting to server [1.2.3.4] port 22.
debug1: Connection established.
debug1: Authentication state: xxx

If it stops at “Connecting” stage, it’s a network/firewall issue, not authentication.

Enable Server-Side Debug Logging

# Check SSH daemon logs
sudo journalctl -u ssh -f

# Or on older systems:
sudo tail -f /var/log/auth.log | grep sshd

Test Network Connectivity

# Does port 22 respond at all?
telnet server 22

# Response should be:
# Trying 1.2.3.4...
# Connected to server
# Escape character is '^]'.
# SSH-2.0-OpenSSH_8.9p1 Ubuntu-3

# If "Connection refused", it's daemon or firewall

Common Misconfigurations

Config 1: SSH Daemon Disabled in sshd_config

sudo cat /etc/ssh/sshd_config | grep "^#"

# Example problematic line:
#Port 22               ← Commented out; daemon ignores this
#PermitRootLogin yes   ← Also commented; SSH uses defaults

Fix: Uncomment critical lines and reload:

sudo systemctl restart ssh

Config 2: Wrong Network Interface Binding

# In sshd_config:
ListenAddress 127.0.0.1    ← Only localhost; no remote access

Fix: Change to:

ListenAddress 0.0.0.0       ← Listen on all interfaces (or specific IP)

Then:

sudo systemctl restart ssh

Config 3: AllowUsers or DenyUsers List Misconfigured

# In sshd_config:
AllowUsers ubuntu root alice    ← Only these users can SSH

# If your user isn't listed, access denied

Fix: Add your user:

AllowUsers ubuntu youruser
sudo systemctl restart ssh

Network Connectivity Verification

From Client Machine

# 1. Can you ping the server?
ping server.local
PING server.local (192.168.1.100) 56(84) bytes of data.
64 bytes from server.local (192.168.1.100): icmp_seq=1 ttl=64 time=2.5ms

# 2. Is port 22 open?
nc -zv server.local 22
Connection to server.local 22 port [tcp/ssh] succeeded!

# Alternative (if nc not installed):
timeout 2 bash -c 'cat < /dev/null > /dev/tcp/server.local/22'
echo $?    ← Exit 0 = port open, 1 = closed

Debugging Flow (Decision Tree)

SSH Connection Refused
│
├─ Can you ping the server?
│  ├─ NO → Network/DNS issue; not SSH daemon
│  │  └─ Fix: Check routing, DNS, firewall at network layer
│  │
│  └─ YES → Continue
│
├─ Does port 22 respond? (telnet server 22)
│  ├─ NO → SSH daemon not listening or firewall blocks
│  │  ├─ Run: sudo systemctl status ssh
│  │  ├─ Run: sudo ufw status
│  │  └─ Apply Fix 1 or Fix 2
│  │
│  └─ YES → SSH daemon responding
│
└─ Does authentication fail after connection?
   ├─ YES → Key/permission issue
   │  └─ Apply Fix 4 or Fix 5
   │
   └─ NO → Check user/password on server

One-Liner Recovery Script

#!/bin/bash
# Run on the server if SSH is broken

sudo systemctl start ssh
sudo systemctl enable ssh
sudo ufw allow 22/tcp
sudo ufw reload
chmod 700 ~/.ssh 2>/dev/null
chmod 600 ~/.ssh/authorized_keys 2>/dev/null
sudo systemctl restart ssh
echo "SSH recovery complete. Test with: ssh -v user@$(hostname -I)"

Prevention Best Practices

1. Monitor SSH daemon health:

   sudo systemctl enable ssh  # Persist across reboots

2. Use firewall properly (allow, don’t deny):

   sudo ufw default deny incoming
   sudo ufw allow 22/tcp
   sudo ufw enable

3. Test remote access before locking out:

   ssh -n user@server "echo Connection works"

4. Keep backups of working configs:

   sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup.$(date +%Y%m%d)

Verdict

90% of “Connection Refused” is fixed by

1. sudo systemctl start ssh
2. sudo ufw allow 22/tcp
3. Verifying with telnet server 22

Test this triad before diving into key/permission issues.

Next Steps

• Can’t SSH into remote server? Start with Fixes 1–3.
• Connection works but auth fails? Move to Fix 4.
• Still stuck? Enable debug (ssh -vvv) and share output on ServerFault/Reddit.

See Also: How to troubleshoot a Linux box without guessing