The SSH client cannot reach the remote server on port 22 within the timeout period. This typically indicates a firewall blocking the connection, the SSH service not running, or network connectivity problems between your machine and the host.
This error occurs when SSH attempts to establish a connection to a remote server but fails to receive a response within the default timeout (usually 30 seconds). The 'Connection timed out' message means the network request was sent but never received a reply, which differs from 'Connection refused' (where the server actively rejects the connection). This can happen at several network layers: your firewall, the server's firewall, intermediate network routers, cloud security groups, or ISP-level blocking.
First, check if you can reach the server at all using ping or a connectivity test. If the server is completely unreachable, networking issues are the root cause.
ping -c 4 hostname.example.com
# or
ping -c 4 192.168.1.100If ping fails, the server is offline or your network can't reach it. If ping succeeds, proceed to the next step.
Use telnet or netcat to test if port 22 is accepting connections. This tells you if the server is listening on port 22.
# Using telnet (may not be installed)
telnet hostname.example.com 22
# Using netcat (better, more reliable)
nc -zv hostname.example.com 22
# Using timeout to prevent hanging
timeout 5 telnet hostname.example.com 22If you get 'Connection refused', the port is closed. If you get 'Connection timed out', the firewall is blocking it. If you get a response with SSH version info, port 22 is open and listening.
Connect to the server using a different method (console, VNC, KVM) and check that sshd is running:
# Check SSH daemon status
sudo systemctl status sshd
# If not running, start it
sudo systemctl start sshd
# Enable it to start on boot
sudo systemctl enable sshdOn older systems without systemd:
sudo service ssh status
sudo service ssh startVerify SSH is listening on port 22:
sudo ss -tlnp | grep ssh
# or
sudo netstat -tlnp | grep sshIf sshd is running but port 22 is blocked, check the server's firewall:
# For UFW (Ubuntu/Debian)
sudo ufw status
sudo ufw allow 22/tcp
# For firewalld (CentOS/RHEL)
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
# For iptables (check rules)
sudo iptables -L -n | grep 22
# If iptables is blocking, allow SSH
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables-save # Make changes persistentIf your server is on a cloud provider, ensure the security group allows inbound SSH:
AWS:
- Security Group > Inbound Rules > Add rule
- Protocol: TCP, Port: 22, Source: Your IP or 0.0.0.0/0 (less secure)
Azure:
- Network security group > Inbound security rules
- Add rule allowing TCP port 22 from your IP
GCP:
- VPC network > Firewall rules
- Create rule allowing tcp:22 traffic
Also check Network ACLs (if used) - they can block traffic before security groups.
If the server is configured to use a non-standard SSH port, you must specify it in your command:
# Default port 22
ssh [email protected]
# Custom port (e.g., 2222)
ssh -p 2222 [email protected]Check the server's SSH configuration to find the actual port:
grep '^Port' /etc/ssh/sshd_configDefault is 22 if this line is commented out.
Use SSH's verbose flags to see exactly where the connection is failing:
# Single verbose
ssh -v [email protected]
# Double verbose (more details)
ssh -vv [email protected]
# Triple verbose (maximum details)
ssh -vvv [email protected]Look for the line where it gets stuck - usually something like:
- 'Trying X.X.X.X...' means it's trying to connect
- No response after this = firewall blocking the connection
- 'Timeout' message = connection timed out (firewall)
- 'Connection refused' = port is closed on server
Some ISPs or corporate networks block port 22 for security. Test this:
# Try using a port known to be open (like 443 for HTTPS)
# Ask your server admin to listen on this alternate port
ssh -p 443 [email protected]
# Or test with a public SSH server (if allowed)
ssh -p 22 [email protected] # GitHub allows SSHIf alternate ports work but 22 doesn't, your network provider may be blocking port 22. Solutions:
- Use a VPN to bypass the block
- Ask your IT/ISP to unblock port 22
- Configure SSH on an alternate port (443, 8022, etc.) with server admin help
If connections work but are slow, increase the client-side timeout:
# Increase timeout to 30 seconds (default is ~20)
ssh -o ConnectTimeout=30 [email protected]Or add to your ~/.ssh/config file:
Host *
ConnectTimeout 30
ServerAliveInterval 60
ServerAliveCountMax 3These settings prevent idle connections from timing out and increase the initial connection timeout for slow networks.
Root cause flow chart: Start with ping to verify network reach. If ping works, use nc -zv to test port 22. If port 22 is closed, check sshd is running. If sshd is running, check firewall rules. If testing from multiple networks and it fails everywhere, the issue is server-side (firewall or sshd). If it fails from some networks (office/VPN) but works from home, the issue is likely ISP/corporate firewall blocking port 22.
Debugging tips: The verbose output -vvv is invaluable - it shows exactly where the connection gets stuck. Pay attention to the IP address SSH is trying to connect to (sometimes DNS resolution is the issue). If you see 'Trying X.X.X.X...' with no response, a firewall between you and the server is blocking traffic. If you see 'connect to host port 22: Connection refused', the server is reachable but sshd isn't listening.
Alternative ports: Some networks block port 22 but allow others. Common alternatives: 443 (HTTPS), 8022, 2222. Require server admin to configure sshd on the alternate port in /etc/ssh/sshd_config.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH