How to Fix SSH Connection Refused Error

You have typed your command, hit Enter, expecting to connect to your server. Instead, you’re greeted with the frustrating SSH Connection Refused error rather than a welcoming shell prompt.

ssh: connect to host your-server port 22: Connection refused

ssh: connect to host your-server port 22: Connection refused

That flat, unhelpful line is one of the most frustrating messages in server management. No explanation. No suggested fix. Just a door slammed in your face.

I have been there more times than I’d like to admit, particularly after spinning up new VPS instances where I’d forgotten to note the custom SSH port, or after a firewall rule I applied broader than intended cut off my own access.

The good news: SSH Connection Refused is almost always fixable in minutes once you know what to check. This guide walks through every real cause I have encountered in practice, with the exact commands that diagnose and resolve each one.

What this guide covers: the meaning behind the error, causes, step-by-step fixes, a prevention checklist, and the FAQs I actually hear from developers.

Who it’s for: anyone managing a Linux server, whether it’s your first VPS or your hundredth.

TL;DR

• SSH Connection Refused means the server is actively rejecting your connection attempt
• The most common causes: wrong port, service not running, firewall blocking, wrong credentials, and SSH not installed
• Most fixes take under 5 minutes from your terminal
• Always verify the fix by attempting to reconnect before assuming the problem is solved
• Prevention: use non-default ports, configure fail2ban, and restrict SSH to specific IPs

What Does “SSH Connection Refused” Actually Mean?

Let’s be precise, because understanding the mechanics changes how you debug.

“Connection Refused” is TCP’s way of saying: I heard you, but I’m not accepting this connection. The server received your SYN packet, processed it, and sent back a RST (reset) flag. This is fundamentally different from a timeout (where the server never responds at all) or an authentication failure (where the server accepts the connection but rejects your credentials).

In SSH terms, this means the SSH daemon, sshd , either isn’t listening on the port you are targeting, isn’t running at all, or something network-level is intercepting the request before it reaches the daemon.

The practical difference matters: if you see “Connection Refused”, you at least know the server is reachable over the network. That’s useful diagnostic information.

If you want to learn more about how SSH works internally, including its configuration options and authentication process, the official OpenSSH documentation provides detailed explanations.

How to Diagnose SSH Connection Refused

Before fixing anything, verify. The most common mistake I see is jumping to conclusions, changing the SSH port when the problem was the firewall, or reinstalling SSH when the service just needed a restart.

Here’s the diagnostic sequence I follow, in order:

Step 1: Confirm the server is reachable at all

ping -c 3 your-server-ip

ping -c 3 your-server-ip

If ping fails, you have a network connectivity issue, possibly the server is down, or it’s on an unreachable network. That’s a different problem than Connection Refused.

Step 2: Check if the SSH port is reachable

nc -zv your-server-ip 22
# or if the port is non-standard:
nc -zv your-server-ip 2222

nc -zv your-server-ip 22
# or if the port is non-standard:
nc -zv your-server-ip 2222

If this shows “Connection refused”, you have confirmation the problem is at the SSH layer.

Step 3: Use SSH verbose mode for more detail

ssh -v username@your-server-ip -p PORT

ssh -v username@your-server-ip -p PORT

The -v flag (use -vvv for maximum verbosity) shows exactly where the connection attempt stalls.

This alone often points you directly to the problem.

The Six Real Causes And How to Fix Them

This is the mental model I have built debugging real servers.

Cause 1: The SSH Service Isn’t Running

This sounds obvious, but it’s more common than people think. A server reboot, a failed upgrade, or an OOM (out-of-memory) kill can stop sshd without you noticing until you try to reconnect.

How to check (from a console/KVM session or a working connection):

sudo systemctl status sshd

sudo systemctl status sshd

If you see Active: inactive (dead) or the service is missing, that’s the problem.

Fix:

sudo systemctl start sshd
sudo systemctl enable sshd   # so it starts on future reboots

sudo systemctl start sshd
sudo systemctl enable sshd   # so it starts on future reboots

On Ubuntu/Debian the service is ssh; on RHEL/CentOS/AlmaLinux it’s sshd. This tripped me up the first time I managed a CentOS box after years on Ubuntu.

What to verify after: run sudo systemctl status sshd again and confirm it shows Active: running. Then attempt your SSH connection again.

If the SSH service keeps stopping unexpectedly, it may indicate server resource exhaustion. Monitoring CPU, RAM, and disk usage can help identify the root cause.

Cause 2: You are Connecting to the Wrong Port

SSH defaults to port 22, but many server administrators, and most cloud providers, change this as a basic security measure. If you are connecting to a non-standard port and don’t specify it, you will get Connection Refused every time.

This caught me off guard repeatedly when managing multiple servers from different providers. Each had its own default port, and ssh your-server always assumed 22.

How to check:

sudo grep "^Port" /etc/ssh/sshd_config

sudo grep "^Port" /etc/ssh/sshd_config

If that line is commented out or shows a different number (say, Port 2222), that’s the issue.

Fix: Specify the port explicitly in your SSH command:

ssh username@your-server-ip -p 2222

ssh username@your-server-ip -p 2222

Or permanently, by editing your local ~/.ssh/config:

Host my-server
    HostName your-server-ip
    User username
    Port 2222

Host my-server
    HostName your-server-ip
    User username
    Port 2222

I keep a ~/.ssh/config file for every server I manage now. It’s saved me from this particular frustration more times than I can count.

Cause 3: The Firewall Is Blocking Your Connection

Firewalls are the most common culprit I see in cloud environments. Ubuntu’s UFW, RHEL’s firewalld, or cloud security groups, any of them can block port 22 (or your custom SSH port) and produce “Connection Refused”.

What makes this tricky: the firewall might have been configured automatically by a control panel, or updated by a system security patch, without you realizing.

How to check on the server:

# For UFW (Ubuntu/Debian)
sudo ufw status

# For firewalld (RHEL/CentOS/AlmaLinux)
sudo firewall-cmd --list-all

# For UFW (Ubuntu/Debian)
sudo ufw status

# For firewalld (RHEL/CentOS/AlmaLinux)
sudo firewall-cmd --list-all

If the SSH port isn’t listed in the rules, it’s being blocked.

Fix: UFW

sudo ufw allow 22/tcp
# or for a custom port:
sudo ufw allow 2222/tcp
sudo ufw reload

sudo ufw allow 22/tcp
# or for a custom port:
sudo ufw allow 2222/tcp
sudo ufw reload

If you are new to Ubuntu’s firewall, the official UFW documentation covers everything from allowing ports to creating advanced firewall rules.

Fix: firewalld

sudo firewall-cmd --permanent --add-service=ssh
# or for a custom port:
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

sudo firewall-cmd --permanent --add-service=ssh
# or for a custom port:
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

For Red Hat-based distributions, the official firewalld documentation provides a detailed reference for the firewall.

For cloud providers (AWS, DigitalOcean, Hetzner, etc.), the firewall is often at the cloud platform level, not on the server itself. Check your cloud console’s security groups or network firewall rules. I once spent 20 minutes debugging an SSH issue on a new server before remembering I’d configured the cloud firewall but forgotten to add the SSH rule.

If you’re using Ubuntu, understanding UFW setup can prevent accidental SSH lockouts.

Cause 4: SSH Isn’t Installed

This happens, particularly with minimal OS images or Docker-based server templates where the SSH server isn’t included by default.

How to check:

which sshd
# or
dpkg -l | grep openssh-server   # Debian/Ubuntu
rpm -qa | grep openssh-server    # RHEL/CentOS

which sshd
# or
dpkg -l | grep openssh-server   # Debian/Ubuntu
rpm -qa | grep openssh-server    # RHEL/CentOS

If nothing comes back, OpenSSH Server isn’t installed.

Fix: Ubuntu/Debian

sudo apt-get update
sudo apt-get install openssh-server

sudo apt-get update
sudo apt-get install openssh-server

Fix: RHEL/CentOS/AlmaLinux

sudo yum install openssh-server
# or
sudo dnf install openssh-server

sudo yum install openssh-server
# or
sudo dnf install openssh-server

After installing, start and enable the service:

sudo systemctl start sshd
sudo systemctl enable sshd

sudo systemctl start sshd
sudo systemctl enable sshd

Cause 5: The SSH Daemon Is Bound to a Different IP

This one is less common but worth knowing. If sshd is configured to listen only on a specific IP address (using the ListenAddress directive in /etc/ssh/sshd_config), and you try connecting to a different IP on the server, you’ll get Connection Refused.

How to check:

sudo grep "^ListenAddress" /etc/ssh/sshd_config

sudo grep "^ListenAddress" /etc/ssh/sshd_config

If it shows ListenAddress 0.0.0.0, SSH is listening on all interfaces. If it shows a specific IP like ListenAddress 192.168.1.100 and you’re trying to connect to the public IP, the daemon won’t respond.

Fix: Edit /etc/ssh/sshd_config and set ListenAddress 0.0.0.0 (or ::), then restart the daemon:

sudo systemctl restart sshd

sudo systemctl restart sshd

Cause 6: SELinux or AppArmor Is Blocking SSH

On RHEL-based systems with SELinux in enforcing mode, incorrect SELinux contexts can prevent sshd from binding to the correct port. Similarly, on Ubuntu with AppArmor, misconfigured profiles can block SSH.

How to check: SELinux

sudo getenforce   # shows Enforcing, Permissive, or Disabled
sudo semanage port -l | grep ssh

sudo getenforce   # shows Enforcing, Permissive, or Disabled
sudo semanage port -l | grep ssh

If SELinux is running but the SSH port isn’t in the allowed list, you’ll see a denial in /var/log/audit/audit.log with “avc: denied.”

Fix: SELinux

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

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

Fix: AppArmor

sudo aa-status | grep sshd
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.sshd

sudo aa-status | grep sshd
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.sshd

Preventing SSH Connection Refused in Production

Fixing the error is one thing. Preventing it is where experience really matters. Here’s what I do on every server I manage:

1. Use a custom SSH port: not 22. Brute-force bots scan port 22 constantly; moving to a high port like 2222 or 3456 reduces noise dramatically. Update /etc/ssh/sshd_config and remember to update your local ~/.ssh/config too.

2. Configure fail2ban: this automatically blocks IPs that fail too many authentication attempts.

On Ubuntu:

sudo apt-get install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

sudo apt-get install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

I once left a test server exposed without fail2ban and woke up to 40,000 brute-force attempts overnight. fail2ban would have blocked that entirely.

3. Restrict SSH access by IP: if your office or home has a static IP, restrict SSH connections to that IP in your firewall rules. Cloud security groups make this particularly easy.

4. Keep SSH config local, not memorized: always use ~/.ssh/config with named hosts, custom ports, and identity files. This eliminates the “wrong port” problem almost entirely.

5. Test your SSH connection after any firewall change: open a second terminal session before modifying firewall rules. This way, if you lock yourself out, you still have the original session open. I’ve used this saved-me approach more than once.

6. Use a control panel such as ServerAvatar: if you’re managing multiple servers, a control panel can handle SSH configuration, firewall rules, and fail2ban from a dashboard, reducing the surface area for these errors.

Common Mistakes to Avoid

1. Don’t assume port 22 is correct. I’ve wasted an embarrassing amount of time on this. Always verify.

2. Don’t restart sshd without a backup session open. If you’re connecting via SSH to fix an SSH problem, keep your current session alive while you test changes in a new session. One wrong sshd config can boot you off permanently.

3. Don’t disable the firewall to test it. If a firewall rule is causing the problem, disabling the firewall fixes the test but leaves you wide open. Instead, add the SSH rule first, then test.

4. Don’t ignore the error message entirely. “Connection Refused” tells you something specific, the port isn’t accepting connections. “Connection Timed Out” tells you something different (network-level issue). Read the error.

Why “Connection Refused” vs. Other SSH Errors Matters

Understanding the difference accelerates debugging:

This distinction has saved me hours of debugging over the years.

Key Takeaways

• SSH Connection Refused means the SSH daemon isn’t accepting connections on the port you’re targeting
• The most common causes are: service not running, wrong port, firewall blocking, SSH not installed, wrong bind address, and security modules blocking access
• Always diagnose before fixing, use verbose SSH mode and ping first
• Keep a backup SSH session open when modifying SSH configuration on a remote server
• Prevention: custom port, fail2ban, IP restriction, and ~/.ssh/config for every server
• Cloud firewall rules are separate from server firewalls, check both

Conclusion

SSH Connection Refused is one of those errors that feels alarming the first few times but becomes routine once you understand the mechanics. The server is telling you exactly what the problem is, there’s no tunnel, no daemon, or something in between is saying no.

The fix is almost always one to three commands away. The real skill is diagnosing which of the six causes is at play, in the right order, without making things worse.

If you’re managing multiple servers and want a simpler way to handle SSH configuration, firewall rules, and server monitoring from a single dashboard, platforms like ServerAvatar are worth exploring. They won’t prevent all SSH errors, but they make the debugging process considerably less stressful.

FAQs

About the Author

Meghna Meghwani is a technical writer focused on Linux, Ubuntu, VPS hosting, server management, WordPress, PHP, Node.js, cloud hosting, and DevOps. She creates beginner-friendly tutorials, practical hosting guides, troubleshooting articles, and server security content designed to help developers and businesses manage applications and servers more efficiently.