The Error
You run a routine SSH command and get hit with:
$ ssh user@192.168.1.100
ssh: connect to host 192.168.1.100 port 22: Connection refused
No timeout, no password prompt — just an immediate refusal. The server responds to ping just fine, but SSH slams the door. That immediate refusal is actually a useful signal: the OS is actively rejecting the connection, which narrows it down to one of three culprits: sshd isn't running, a firewall is blocking port 22, or SSH moved to a non-standard port.
Diagnose First
Don't start changing things blindly. Two quick checks from the client side will tell you a lot:
# Check if port 22 is open at all
nc -zv 192.168.1.100 22
# Or use nmap if nc isn't available
nmap -p 22 192.168.1.100
Connection refused from nc means the port is actively closed — the OS itself is sending back a TCP RST packet. That's different from a silent drop (which causes a timeout). A firewall that drops packets silently would hang for 30–60 seconds before giving up. Immediate refusal means something else is going on.
If you have console or VNC access to the server, also run:
# Check what's listening on port 22
ss -tlnp | grep 22
# Or on older systems
netstat -tlnp | grep 22
Fix 1: SSH Daemon Is Not Running
Nine times out of ten, this is it. The sshd service crashed, was never enabled, or failed silently after a config change.
# Check the service status
sudo systemctl status sshd
# On some distros it's named ssh instead of sshd
sudo systemctl status ssh
If it shows inactive or failed, start it:
# Start immediately
sudo systemctl start sshd
# Also enable it to survive reboots
sudo systemctl enable sshd
If the service refuses to start, the logs will tell you why:
sudo journalctl -u sshd -n 50 --no-pager
Typical culprits: a typo in /etc/ssh/sshd_config, missing host keys (usually after a botched migration), or another process already sitting on port 22. Fix the underlying issue, then start the service again.
Fix 2: Firewall Is Blocking Port 22
sshd can be running and healthy while a firewall rule quietly blocks every incoming connection. Check the firewall first.
UFW (Ubuntu/Debian)
# Check current rules
sudo ufw status
# Allow SSH
sudo ufw allow ssh
# Or explicitly by port
sudo ufw allow 22/tcp
firewalld (CentOS/RHEL/Fedora)
# Check if SSH service is allowed
sudo firewall-cmd --list-services
# Add SSH permanently
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
iptables (raw rules)
# Check existing rules
sudo iptables -L INPUT -n -v
# Allow port 22
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Save rules (Debian/Ubuntu)
sudo iptables-save | sudo tee /etc/iptables/rules.v4
Fix 3: SSH Is Listening on a Different Port
Many hardened servers move SSH off port 22 to reduce noise from automated scanners. Port 2222 is a popular alternative. Find out what port sshd is actually using:
# Check the configured port (run this on the server)
sudo grep -i ^Port /etc/ssh/sshd_config
No output means it's still using the default port 22. If you see a different number, connect with -p:
ssh -p 2222 user@192.168.1.100
Tired of typing the port every time? Add a host entry to ~/.ssh/config on your client:
Host myserver
HostName 192.168.1.100
User user
Port 2222
After that, ssh myserver is all you need.
Fix 4: SSH Not Installed on the Server
Fresh containers and minimal server installs often skip OpenSSH entirely. Worth checking if nothing else explains the refusal.
# Debian/Ubuntu
sudo apt update && sudo apt install openssh-server -y
# CentOS/RHEL
sudo dnf install openssh-server -y
# Start and enable in one shot
sudo systemctl enable --now sshd
Verification
After applying any fix, confirm port 22 is accepting connections before trying SSH:
# From the client
nc -zv 192.168.1.100 22
# Expected: Connection to 192.168.1.100 22 port [tcp/ssh] succeeded!
# Then try SSH
ssh user@192.168.1.100
On the server side, confirm sshd is actually bound to the port:
ss -tlnp | grep sshd
# Should show: LISTEN 0 128 0.0.0.0:22 ...
Tips
- Cloud VMs (AWS/GCP/Azure): The in-OS firewall isn't the only layer. Security groups and network ACLs sit outside the VM entirely, and a blocked port 22 at the cloud level produces the exact same error regardless of what UFW or iptables says inside. Always check both layers.
- Banned by fail2ban? If you recently had a string of failed login attempts, tools like fail2ban may have automatically blocked your IP. Check with
sudo fail2ban-client status sshd. If your IP is in the banned list, unban it:sudo fail2ban-client set sshd unbanip YOUR_IP. - Network planning: When setting up SSH access across subnets or VPNs, figuring out which CIDR ranges to whitelist can get tedious fast. The Subnet Calculator at ToolCraft handles the math in the browser — no install needed.