Interactive Troubleshooter

Published: Oct 18, 2026

SSH Connection Refused on Port 22 But Service Running - Firewall Tree

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

Comprehensive diagnostic troubleshooting tree for resolving 'Connection refused' errors on SSH port 22 when the SSH service is confirmed active and running. Covers local packet filters, SELinux/AppArmor policies, cloud security groups, and TCP wrapper rules.

Full Diagnostic Tree & Step-by-Step Overview

Where does the connection refusal occur or what is the primary environment layer exhibiting the SSH port 22 failure?

Local OS packet filtering layers (UFW, iptables, nftables, or Fail2ban)
Host access control and mandatory access control policies (SELinux, AppArmor, TCP Wrappers)
Cloud infrastructure and perimeter network firewalls (Security Groups, Network ACLs, Routers)
Daemon binding configuration, loopback restrictions, or non-standard port mismatches

Which local Linux packet filtering or firewall utility is active on the target server?

UFW (Uncomplicated Firewall) blocking port 22 or enforcing strict default deny rules
Raw iptables INPUT chain rules dropping or rejecting incoming TCP SYN packets on port 22
Nftables table ruleset dropping SSH traffic due to interface mismatch or table priority
Fail2ban or automated intrusion prevention daemon banning the client IP address

Fixing UFW (Uncomplicated Firewall) Port 22 Blocking Rules

Solution:

Root Cause: UFW Default Deny Policy without Explicit SSH Rule

When UFW is enabled with default incoming policies set to deny (sudo ufw default deny incoming), any network port not explicitly opened via an allow rule will reject incoming TCP connection requests. Even if sshd is running and listening on port 22, the netfilter kernel module intercepts incoming TCP SYN packets on port 22 and immediately replies with an ICMP Port Unreachable or TCP RST packet, resulting in an instant 'Connection refused' on the client side.

Diagnostic Verification:

Check active UFW status and rule lists:

bash
sudo ufw status verbose

Verify if rule for OpenSSH or port 22 is present in the output.

Inspect kernel logs for dropped packets:

bash
sudo grep -i ufw /var/log/kern.log | tail -n 20

Step-by-Step Fix:

1.Allow SSH Connections via UFW:

Add an explicit allow rule for port 22 or the OpenSSH application profile:

bash
   sudo ufw allow ssh

Alternatively, specify port 22 explicitly:

bash
   sudo ufw allow 22/tcp

2.Reload UFW Rules:

Apply rule changes without dropping existing valid connections:

bash
   sudo ufw reload

3.Verify UFW Status:

bash
   sudo ufw status numbered

4.Test Local Socket Connectivity:

From the local host, test TCP handshake using netcat or telnet:

bash
nc -zv 127.0.0.1 22

Prevention & Long-Term Monitoring:

Always enable UFW application profiles (sudo ufw allow OpenSSH) and test connection persistence before logging out of remote admin sessions.

Resolving Raw iptables INPUT Chain TCP Packet Rejection

Solution:

Root Cause: iptables INPUT Policy Set to DROP/REJECT for Port 22

Low-level netfilter configuration via raw iptables rules may explicitly drop or reject incoming packets destined for port 22. If the default policy for the INPUT chain is DROP, or if a preceding custom rule matches and rejects traffic before reaching the ACCEPT rule, SSH connections are refused at the kernel packet processing stage.

Diagnostic Verification:

List all active iptables rules with line numbers and packet counters:

bash
sudo iptables -L INPUT -v -n --line-numbers

Check if rule policies show DROP or REJECT for TCP destination port 22.

Step-by-Step Fix:

1.Insert Explicit ACCEPT Rule for Port 22:

Insert an accept rule at the top (position 1) of the INPUT chain:

bash
   sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT

2.Save iptables Rules Persistently:

Save rules to prevent loss upon reboot (depending on distribution):

bash
   sudo apt-get install iptables-persistent
   sudo netfilter-persistent save

On RHEL/CentOS systems:

bash
   sudo service iptables save

3.Verify Rule Evaluation Order:

bash
   sudo iptables -L INPUT -v -n

Prevention & Long-Term Monitoring:

Implement configuration management tools (Ansible, Puppet) to manage iptables rulesets atomically and prevent accidental lockouts.

Correcting Nftables Ruleset Blocking SSH Port 22 Traffic

Solution:

Root Cause: Nftables Filter Table Dropping Incoming TCP Port 22 Connections

Modern Linux distributions utilizing nftables as the default packet filtering framework enforce rulesets defined in /etc/nftables.conf. If the base hook chain for inbound traffic (input) drops packets lacking an explicit TCP accept rule for port 22, the network stack terminates incoming SSH handshakes.

Diagnostic Verification:

Inspect active nftables ruleset tables and chains:

bash
sudo nft list ruleset

Verify whether tcp dport 22 has a corresponding accept verdict.

Step-by-Step Fix:

1.Add Accept Rule for Port 22 in Nftables:

Add an allow rule to the inet filter input chain:

bash
sudo nft add rule inet filter input tcp dport 22 accept

2.Make Nftables Rules Persistent:

Update the configuration file at /etc/nftables.conf to include the rule permanently:

bash
   sudo nft list ruleset > /etc/nftables.conf

3.Enable and Restart Nftables Service:

bash
   sudo systemctl enable nftables
   sudo systemctl restart nftables

Prevention & Long-Term Monitoring:

Test syntax changes using nft -c -f /etc/nftables.conf before restarting nftables services.

Unblocking Client IP Addresses Flagged by Fail2ban Jails

Solution:

Root Cause: Fail2ban Intrusion Prevention System IP Ban Triggered

Fail2ban monitors authentication logs (/var/log/auth.log) for repeated failed login attempts. When a threshold is exceeded, Fail2ban dynamically injects firewall rules (via iptables, nftables, or UFW) to drop all incoming TCP packets from the offender's IP address. This results in an immediate connection refusal or timeout for the affected client.

Diagnostic Verification:

Check status of the sshd jail in Fail2ban:

bash
sudo fail2ban-client status sshd

Verify if your client IP address is listed under the banned IP list.

Step-by-Step Fix:

1.Unban Client IP Address:

Remove your IP address from the sshd jail ban list:

bash
   sudo fail2ban-client set sshd unbanip YOUR_CLIENT_IP

2.Add IP to Fail2ban Whitelist:

Prevent future accidental bans by editing /etc/fail2ban/jail.local:

ini
   [DEFAULT]
   ignoreip = 127.0.0.1/8 YOUR_TRUSTED_IP_CIDR

3.Restart Fail2ban Service:

bash
   sudo systemctl restart fail2ban

Prevention & Long-Term Monitoring:

Use SSH key-based authentication instead of passwords to eliminate brute-force authentication failures that trigger Fail2ban jails.

Which host access control or mandatory security policy layer is rejecting the connection?

TCP Wrappers (/etc/hosts.allow and /etc/hosts.deny) explicitly denying access
SELinux (Security-Enhanced Linux) blocking sshd socket binding or connection acceptance
AppArmor security profile confining sshd and denying network socket operations
SSH daemon ListenAddress misconfiguration binding strictly to loopback (127.0.0.1)

Resolving TCP Wrappers Access Denials in hosts.allow and hosts.deny

Solution:

Root Cause: TCP Wrappers Explicit Deny Rule for SSH Daemon

Older Linux distributions or builds compiled with libwrap support check TCP Wrappers configuration files (/etc/hosts.allow and /etc/hosts.deny) prior to spawning an SSH session. If /etc/hosts.deny contains sshd: ALL and /etc/hosts.allow lacks a corresponding permit rule for your client IP, the TCP connection is accepted at the kernel socket layer but immediately closed by sshd accompanied by a connection refused message.

Diagnostic Verification:

Inspect auth logs for TCP wrapper rejection messages:

bash
grep -i "refused connect" /var/log/auth.log

Check contents of /etc/hosts.deny and /etc/hosts.allow:

bash
cat /etc/hosts.deny
cat /etc/hosts.allow

Step-by-Step Fix:

1.Edit /etc/hosts.allow to Permit Client Access:

Open hosts.allow in a text editor and add an explicit allow rule:

text
   sshd: ALL

Or restrict access to specific subnets:

text
   sshd: 192.168.1.0/24

2.Verify hosts.deny Configuration:

Ensure /etc/hosts.deny does not contain blanket denial rules that override allow entries without correct ordering.

3.Test SSH Daemon Service Response:

Attempt reconnection from the client workstation.

Prevention & Long-Term Monitoring:

Modern OpenSSH versions have deprecated TCP Wrappers; migrate access control policies to native SSH daemon configurations (AllowUsers) and firewall rulesets.

Fixing SELinux Policy Violations Blocking SSH Port 22

Solution:

Root Cause: SELinux Context Misconfiguration or Port Mapping Conflict

On SELinux-enforced systems (RHEL, CentOS, Fedora, Rocky Linux), sshd must run under the correct security context (sshd_t), and port 22 must be bound to the allowed SELinux port type (ssh_port_t). If port 22 was modified or if filesystem labeling is corrupt, SELinux blocks the daemon from accepting socket connections, resulting in connection refusal.

Diagnostic Verification:

Check SELinux status:

bash
sestatus

Inspect audit logs for AVC denial rejections involving sshd:

bash
sudo grep -i avc /var/log/audit/audit.log | grep -i sshd

Verify port labeling in SELinux policy:

bash
sudo semanage port -l | grep ssh_port_t

Step-by-Step Fix:

1.Add Port 22 to SELinux Port Type (If modified):

If running SSH on a custom port (e.g., 2222), assign it to ssh_port_t:

bash
   sudo semanage port -a -t ssh_port_t -p tcp 2222

2.Restore Default File Contexts:

Fix potential filesystem context corruption on binary executables:

bash
   sudo restorecon -v /usr/sbin/sshd

3.Temporarily Test in Permissive Mode:

Verify if SELinux is causing the rejection by switching to permissive mode:

bash
   sudo setenforce 0

If connection succeeds, analyze AVC denials using audit2why to craft custom policy modules.

Prevention & Long-Term Monitoring:

Always use semanage port rather than raw policy bypasses when changing default SSH operational ports on hardened systems.

Resolving AppArmor Profile Restrictions on OpenSSH Server

Solution:

Root Cause: AppArmor Enforce Mode Denying Socket Operations for sshd

Ubuntu and Debian derivatives utilize AppArmor as a Mandatory Access Control (MAC) framework. If the AppArmor profile for usr.sbin.sshd is set to enforce mode and contains rule syntax errors or blocks network socket creation, incoming TCP connections on port 22 will be refused.

Diagnostic Verification:

Check AppArmor status for sshd profile:

bash
sudo aa-status

Inspect kernel log for AppArmor rejection events:

bash
sudo grep -i apparmor /var/log/kern.log | grep -i sshd

Step-by-Step Fix:

1.Switch AppArmor Profile to Complain Mode:

Put the sshd profile into complain mode to test connectivity without dropping packets:

bash
   sudo aa-complain /etc/apparmor.d/usr.sbin.sshd

2.Reload AppArmor Profiles:

bash
   sudo systemctl reload apparmor

3.Fix Profile Denials and Enforce:

Review audit logs, update profile rules in /etc/apparmor.d/usr.sbin.sshd, and return to enforce mode:

bash
   sudo aa-enforce /etc/apparmor.d/usr.sbin.sshd

Prevention & Long-Term Monitoring:

Keep AppArmor userland utilities updated to prevent profile parsing bugs during distribution package upgrades.

Fixing SSH Daemon ListenAddress Binding to Loopback Interface

Solution:

Root Cause: sshd_config ListenAddress Bound to 127.0.0.1

The SSH daemon configuration file (/etc/ssh/sshd_config) contains a ListenAddress directive. If this parameter is explicitly set to 127.0.0.1 (loopback) or an internal VLAN IP address, sshd will listen exclusively on that interface. External connection attempts targeting the public network interface on port 22 will find no listening socket on that IP, resulting in an immediate connection refusal.

Diagnostic Verification:

Inspect active socket listeners and bound IP addresses:

bash
sudo ss -tulpn | grep sshd

Check if the output shows binding to 127.0.0.1:22 or [::1]:22 instead of 0.0.0.0:22 or :::22.

Step-by-Step Fix:

1.Edit SSH Daemon Configuration File:

Open /etc/ssh/sshd_config with administrative privileges:

bash
   sudo nano /etc/ssh/sshd_config

2.Update ListenAddress Directive:

Locate ListenAddress and ensure it is commented out (defaulting to all interfaces) or explicitly set to listen on all IP addresses:

text
   ListenAddress 0.0.0.0
   ListenAddress ::

3.Test Configuration Syntax:

bash
   sudo sshd -t

4.Restart SSH Daemon Service:

bash
   sudo systemctl restart sshd

Prevention & Long-Term Monitoring:

Always execute sshd -t configuration syntax validation before restarting the SSH service to prevent binding lockouts.

Where in the cloud or perimeter network infrastructure is the connection drop occurring?

Cloud Provider Security Group or Network Security Group (AWS, Azure, GCP) missing inbound port 22 rule
Virtual Private Cloud (VPC) Network ACLs or subnet route tables blocking return traffic
Hardware edge router, corporate firewall, or ISP carrier-grade NAT (CGNAT) blocking inbound SSH
Floating IP, NAT gateway, or public load balancer misconfigured port forwarding rules

Configuring Cloud Security Group Inbound Rules for Port 22

Solution:

Root Cause: Cloud Provider Security Group Blocking Inbound Port 22

Cloud virtual machines hosted on AWS (EC2), Azure (Network Security Groups), or Google Cloud Platform (VPC Firewall Rules) operate behind hypervisor-level virtual firewalls. If the inbound security group rule does not explicitly permit TCP port 22 from your client IP address (or 0.0.0.0/0 for public access), the cloud provider's virtual switch drops the incoming TCP SYN packet before it ever reaches the guest operating system.

Diagnostic Verification:

Access your cloud provider's management console or CLI.

Inspect the attached Security Group or Firewall rule sets for the target instance.

Verify whether TCP port 22 allows inbound traffic from your client IP or CIDR block.

Step-by-Step Fix:

1.Add Inbound Security Group Rule:

In AWS EC2, navigate to Security Groups > Edit inbound rules.

Add rule: Type: SSH, Protocol: TCP, Port Range: 22, Source: My IP (or specific CIDR).

In Azure, go to Networking > Add inbound port rule for port 22.

2.Save and Apply Rules:

Save the security group configuration changes.

3.Test Remote Connectivity:

Verify TCP handshake from client workstation:

bash
   nc -zv <PUBLIC_INSTANCE_IP> 22

Prevention & Long-Term Monitoring:

Enforce Infrastructure as Code (Terraform, CloudFormation) templates with standardized secure SSH access baselines across all cloud environments.

Resolving VPC Network ACLs and Subnet Routing Stateless Drops

Solution:

Root Cause: Stateless VPC Network ACL Blocking Return Traffic

Unlike stateful Security Groups, cloud Virtual Private Cloud (VPC) Network ACLs (NACLs) are stateless. This means inbound allow rules for TCP port 22 must be accompanied by explicit outbound allow rules for ephemeral return ports (typically TCP 1024-65535) in the NACL rule table. If outbound ephemeral ports are denied, the server receives the SSH connection request but cannot transmit return packets back to the client.

Diagnostic Verification:

Inspect the Network ACL associated with the subnet hosting your virtual machine instance.

Check both Inbound Rules (allowing port 22) and Outbound Rules (allowing ports 1024-65535).

Step-by-Step Fix:

1.Add Outbound Ephemeral Port Rule to NACL:

In your cloud console, edit the subnet NACL outbound rules.

Add a rule allowing outbound traffic on TCP ports 1024-65535 destined for 0.0.0.0/0.

2.Verify Inbound Port 22 Rule:

Ensure rule evaluation number places the allow rules before default DENY ALL rules.

3.Test Connection Persistence:

bash
   ssh -v user@server_ip

Prevention & Long-Term Monitoring:

Prefer stateful Security Groups for instance-level filtering and reserve stateless NACLs for coarse subnet boundary perimeters.

Bypassing Edge Router and ISP Port 22 Blocking / CGNAT

Solution:

Root Cause: ISP Port 22 Filtering or Carrier-Grade NAT (CGNAT) Interference

Many consumer Internet Service Providers (ISPs) block inbound traffic on port 22 at the gateway level to mitigate worm propagation and brute-force attacks. Additionally, Carrier-Grade NAT (CGNAT) assigns private IP addresses behind shared public gateways, preventing direct inbound TCP handshakes unless port forwarding or a tunneling mechanism is established.

Diagnostic Verification:

Perform a port scan from an external remote network (e.g., mobile hotspot) using nmap:

bash
nmap -p 22 -Pn <YOUR_PUBLIC_IP>

If the port reports filtered, the ISP or edge router firewall is dropping packets before reaching your host.

Step-by-Step Fix:

1.Configure Port Forwarding on Edge Router:

Log into your local router admin panel, navigate to Port Forwarding / Virtual Server, and forward external port 22 to internal server IP port 22.

2.Switch to an Alternative External Port:

If the ISP blocks port 22, reconfigure sshd to listen on a non-standard external port (e.g., Port 2222) and forward router port 2222 to internal port 22.

3.Utilize Reverse Tunneling or VPN:

For CGNAT environments, establish an outbound WireGuard VPN or Tailscale mesh network to access the server securely without public port forwarding.

Prevention & Long-Term Monitoring:

Request a dedicated public static IP or business-class broadband package from your ISP if inbound port accessibility is required.

Fixing Floating IP and Load Balancer Port Forwarding Mismatches

Solution:

Root Cause: Floating IP Routing or Load Balancer Target Group Misconfiguration

When accessing a server through a cloud Floating IP, Elastic IP, or Layer 4 Load Balancer, incoming connections hit the load balancer's frontend listener on port 22. If backend target instances are improperly mapped, health checks fail, or target group security groups reject traffic forwarded from the load balancer, connections are refused.

Diagnostic Verification:

Check load balancer target health status in the cloud console.

Verify if target instance security groups allow incoming traffic from the load balancer's private IP range.

Step-by-Step Fix:

1.Configure Load Balancer Listener Rules:

Ensure the load balancer frontend listener is configured for TCP Port 22 forwarding to backend instances on Port 22.

2.Update Target Group Security Group:

Modify the instance security group to allow inbound TCP 22 traffic originating from the Load Balancer security group ID.

3.Test Direct vs Load Balanced IP:

Connect directly to the instance private/public IP to isolate load balancer routing failures.

Prevention & Long-Term Monitoring:

Implement infrastructure health checks on TCP port 22 within load balancer target groups for automated failover monitoring.

What daemon binding state or protocol configuration mismatch is present on the server?

SSH daemon is listening on a non-standard port (e.g., Port 2222) while client attempts connection on Port 22
IPv4 vs IPv6 socket family binding conflict causing connection rejection
Network interface binding restriction (ListenAddress bound to internal VLAN interface)
Socket exhaustion or SYN backlog queue saturation on the sshd listening port

Fixing Port Mismatches When SSH Runs on Non-Standard Ports

Solution:

Root Cause: Client Targeting Port 22 While Daemon Listens on Custom Port

For security hardening, administrators frequently reconfigure sshd to listen on a non-standard port (e.g., Port 2222) in /etc/ssh/sshd_config. If a client attempts to connect using default parameters (ssh user@server), the client targets port 22. Because port 22 either has no listening daemon or is blocked, the kernel returns an immediate connection refused error.

Diagnostic Verification:

Check active listening ports on the server:

bash
sudo ss -tulpn | grep sshd

Verify whether the daemon listens on port 22 or a custom port number.

Step-by-Step Fix:

1.Specify Custom Port in Client Connection Command:

Connect explicitly using the -p flag:

bash
   ssh -p 2222 user@server_ip

2.Configure Client SSH Config File:

Add a persistent host block in ~/.ssh/config on your client workstation:

text
   Host myserver
       HostName server_ip
       User myuser
       Port 2222

3.Revert to Port 22 (If Custom Port Unintentional):

Edit /etc/ssh/sshd_config, uncomment Port 22, and restart sshd.

Prevention & Long-Term Monitoring:

Document non-standard administrative port allocations in your internal organization runbooks.

Resolving IPv4 and IPv6 Socket Family Binding Conflicts

Solution:

Root Cause: IPv6 Dual-Stack Socket Binding Collision

On modern Linux systems with IPv6 enabled, OpenSSH attempts to bind to both IPv4 and IPv6 sockets (AddressFamily any). If IPv6 networking is partially disabled via sysctl parameters (net.ipv6.conf.all.disable_ipv6 = 1) while sshd attempts dual-stack binding, socket allocation fails or refuses incoming IPv4 connection attempts on port 22.

Diagnostic Verification:

Check active socket bindings for IPv4 vs IPv6:

bash
sudo ss -tulpn | grep sshd

Look for address families showing :::22 vs 0.0.0.0:22.

Step-by-Step Fix:

1.Explicitly Force IPv4 Address Family in sshd_config:

Open /etc/ssh/sshd_config and set the AddressFamily directive:

text
   AddressFamily inet

2.Test Configuration Syntax:

bash
   sudo sshd -t

3.Restart SSH Service:

bash
   sudo systemctl restart sshd

Prevention & Long-Term Monitoring:

Ensure consistent IPv6 kernel sysctl configurations across your entire server fleet to avoid socket binding discrepancies.

Correcting VLAN and Internal Network Interface Binding Restrictions

Solution:

Root Cause: ListenAddress Bound to Specific Internal VLAN Interface IP

Multi-homed servers possessing multiple network interfaces (e.g., eth0 public, eth1 internal VLAN) can be configured in sshd_config to listen solely on the internal VLAN IP address. When external clients attempt connecting to the public interface IP on port 22, the network stack rejects the connection because no listening socket exists on that interface.

Diagnostic Verification:

List server network interfaces and assigned IP addresses:

bash
ip addr show

Check ListenAddress directives in /etc/ssh/sshd_config.

Step-by-Step Fix:

1.Bind SSH Daemon to All Interfaces or Specific Public IP:

Update /etc/ssh/sshd_config to bind to 0.0.0.0 or the specific public IP address:

text
   ListenAddress 0.0.0.0

2.Restart SSH Service:

bash
   sudo systemctl restart sshd

Prevention & Long-Term Monitoring:

Use explicit IP binding on multi-homed bastion hosts to restrict administrative access strictly to secure internal management VLANs.

Mitigating Socket Exhaustion and SYN Backlog Queue Saturation

Solution:

Root Cause: SYN Backlog Queue Saturation and Connection Exhaustion

During a massive brute-force attack or high-concurrency connection surge, the TCP SYN backlog queue for port 22 becomes entirely saturated. When the queue is full, the Linux kernel drops incoming TCP SYN packets without responding, which clients interpret as a connection refused or timeout error even though the sshd process remains running.

Diagnostic Verification:

Check current socket statistics and listen queue drops for port 22:

bash
ss -lnt '( sport = :22 )'

Check kernel logs for SYN backlog overflow warnings:

bash
dmesg | grep -i "possible SYN flooding"

Step-by-Step Fix:

1.Increase TCP SYN Backlog Queue Size via Sysctl:

Edit /etc/sysctl.conf and increase backlog parameters:

text
   net.ipv4.tcp_max_syn_backlog = 4096
   net.core.somaxconn = 1024

2.Enable TCP SYN Cookies:

text
   net.ipv4.tcp_syncookies = 1

3.Apply Sysctl Changes:

bash
   sudo sysctl -p

Prevention & Long-Term Monitoring:

Deploy fail2ban and rate-limiting firewall rules to drop malicious connection floods before reaching the TCP SYN backlog queue.

Related Diagnostic Guides

Ubuntu Black Screen After Nvidia Driver Install - Secure Boot Diagnostic

Linux Boot Stuck at GRUB Rescue After Windows Update - Dual Boot Fix

SmartScreen Can't Be Reached Right Now Error Fix - Windows Diagnostic Guide

Account Locked After Too Many Attempts in Microsoft 365 - Admin Unlock Tree

Windows 11 Wi-Fi Connected but No Internet? How to Fix It

Subscribe to StepDiag

Embed Guide on Your Website