How to fix packet_write_poll: Connection to hostname port 22: Connection timed out in SSH

First, test if the server is reachable on the network. If ping fails, the server is offline or unreachable at the network layer.

ping -c 4 hostname.example.com
# or with IP address
ping -c 4 192.168.1.100

If ping succeeds, the server is online and reachable. If ping times out, the server is offline or completely unreachable - address this before continuing. If DNS resolution fails, try with an IP address instead.

Note: Some servers disable ICMP ping responses, so timeout here doesn't definitively mean the server is down.

Check if the server is listening on port 22. This tells you if the port is open, closed, or blocked by a firewall.

# Using telnet (may not be installed by default)
telnet hostname.example.com 22

# Using netcat (preferred, more reliable)
nc -zv hostname.example.com 22

# Using timeout to prevent hanging indefinitely
timeout 5 nc -zv hostname.example.com 22

Interpret the results:
- Success message with SSH version = port 22 is open and sshd is running
- "Connection refused" = port 22 is closed (sshd not running or wrong port)
- "Connection timed out" or no response = firewall is blocking the connection
- Hangs indefinitely = either firewall is silently dropping packets or network is slow

Connect to the server using an alternative method (console, KVM, VNC, or cloud provider web console) and verify sshd is running:

# Check SSH daemon status
sudo systemctl status sshd

# If not running, start it
sudo systemctl start sshd

# Enable to start automatically on boot
sudo systemctl enable sshd

On older Linux systems without systemd:

sudo service ssh status
sudo service ssh start

Verify SSH daemon is actually listening on port 22:

sudo ss -tlnp | grep ssh
# or with netstat (older systems)
sudo netstat -tlnp | grep ssh

If the output shows sshd listening on port 22, the daemon is running correctly.

Verify that sshd is configured to listen on port 22 (the default):

# Check SSH server configuration
sudo cat /etc/ssh/sshd_config | grep '^Port'

If you see Port 22 or the line is commented out (which means it defaults to 22), that's correct. If you see a different port number like Port 2222, the SSH server is listening on that port instead:

# If SSH is on a non-standard port, use -p flag
ssh -p 2222 user@hostname.com

If you need to change the port back to 22 (or to a custom port), edit /etc/ssh/sshd_config and restart sshd:

sudo nano /etc/ssh/sshd_config
# Change Port line or uncomment it
# Save and exit
sudo systemctl restart sshd

Even if sshd is running, the server's firewall might be blocking port 22. Check and allow it:

For UFW (Ubuntu/Debian):

sudo ufw status
sudo ufw allow 22/tcp
sudo ufw reload

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 port 22 is not allowed, add it
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables-save  # Make persistent (varies by distro)

After allowing port 22, test the connection again from your client.

If the server is on AWS, Azure, GCP, or another cloud provider, the cloud's security rules may be blocking port 22.

AWS EC2:
- Go to EC2 Dashboard > Instances
- Select your instance
- Click on Security tab
- Click Security Group link
- Check Inbound Rules
- Add rule: Protocol=TCP, Port=22, Source=Your IP (or 0.0.0.0/0 to allow all)
- Also check Network ACL rules if in use

Azure Virtual Machines:
- Go to VM > Networking
- Check Network security group
- Click Inbound security rules
- Add rule: Source=Your IP, Destination Port=22, Protocol=TCP, Action=Allow

GCP Compute Engine:
- Go to VPC network > Firewall rules
- Create rule: Allow protocol=tcp, destination-ports=22
- Set source IP range to your IP or 0.0.0.0/0

After updating rules, test SSH connection again.

Use SSH's verbose flags to see exactly where the connection attempt fails:

# Single verbose (basic connection info)
ssh -v user@hostname.com

# Double verbose (more details about authentication)
ssh -vv user@hostname.com

# Triple verbose (maximum debugging info)
ssh -vvv user@hostname.com

Look for these key lines:
- "Trying X.X.X.X..." = SSH is attempting to connect to this IP
- Hangs here with no response = firewall is silently blocking (not rejecting)
- "Connection refused" after this = port 22 is closed on server
- "Connection timed out" = packet_write_poll error, firewall is blocking
- "socket: Connection reset by peer" = firewall is actively rejecting

The verbose output will clearly show at which network layer the connection fails.

Some ISPs and corporate networks block port 22 for security reasons. Test if this is the case:

# Try connecting via GitHub (which allows SSH on port 22)
ssh -v git@github.com

# If this works, port 22 is generally open on your network
# If this times out, your ISP/network may be blocking port 22

Alternatively, ask your server admin to configure SSH on an alternate port (443, 8022, etc.) and test:

ssh -p 443 user@hostname.com

If alternate ports work but port 22 doesn't:
- Use a VPN to bypass the block
- Request your ISP/corporate IT to unblock port 22
- Configure SSH on the alternate port permanently (requires server changes)

If the connection eventually works but is slow, increase the timeout:

# Increase timeout to 30 seconds (default ~20 seconds)
ssh -o ConnectTimeout=30 user@hostname.com

Make this persistent by adding to ~/.ssh/config:

Host *
    ConnectTimeout 30
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host specific.hostname.com
    ConnectTimeout 60

These settings:
- ConnectTimeout: How long to wait for initial connection (in seconds)
- ServerAliveInterval: Send keepalive packets every 60 seconds
- ServerAliveCountMax: Disconnect if 3 keepalive packets are unanswered

Useful for slow or unreliable networks.