The SSH client cannot reach the remote server on port 22 within the timeout period. The packet_write_poll error indicates the TCP connection attempt failed to establish. This typically means a firewall is blocking the connection, the SSH service isn't running, or there are network routing issues.
The packet_write_poll error occurs when SSH attempts to send data through the TCP connection socket but fails because the connection was never established. This happens at the network layer when the client sends a SYN packet to initiate a TCP handshake on port 22, but receives no response from the server (no SYN-ACK). This differs from 'Connection refused' where the server actively rejects the connection. The timeout indicates the network request was sent but never received a response, which can happen due to firewall filtering, routing problems, the SSH daemon not running, or the host being completely unreachable.
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.100If 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 22Interpret 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 sshdOn older Linux systems without systemd:
sudo service ssh status
sudo service ssh startVerify SSH daemon is actually listening on port 22:
sudo ss -tlnp | grep ssh
# or with netstat (older systems)
sudo netstat -tlnp | grep sshIf 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 [email protected]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 sshdEven 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 reloadFor firewalld (CentOS/RHEL):
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadFor 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 [email protected]
# Double verbose (more details about authentication)
ssh -vv [email protected]
# Triple verbose (maximum debugging info)
ssh -vvv [email protected]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 [email protected]
# If this works, port 22 is generally open on your network
# If this times out, your ISP/network may be blocking port 22Alternatively, ask your server admin to configure SSH on an alternate port (443, 8022, etc.) and test:
ssh -p 443 [email protected]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 [email protected]Make this persistent by adding to ~/.ssh/config:
Host *
ConnectTimeout 30
ServerAliveInterval 60
ServerAliveCountMax 3
Host specific.hostname.com
ConnectTimeout 60These 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.
Understanding packet_write_poll: The packet_write_poll error message indicates the kernel attempted to write data to a TCP socket but failed because the connection was never established. At the TCP level, the client sends a SYN packet, waits for a SYN-ACK response, but the response never arrives within the timeout period. This is a network-layer issue, not an application-layer SSH issue.
Firewall behavior differences: A key diagnostic detail is how the firewall handles rejected connections: Some firewalls (stateful) send a RST (reset) packet and the error is 'Connection refused'. Other firewalls (stateless) silently drop packets and the error is 'Connection timed out' (packet_write_poll). Both indicate the port is blocked, but the behavior differs.
Root cause diagnosis flowchart: 1) Ping works? = server is reachable. 2) Port 22 test (nc) times out? = firewall blocking. 3) Port 22 test succeeds? = firewall not blocking, check server-side. 4) sshd running? = yes, check port config. 5) Port config wrong? = update /etc/ssh/sshd_config. If all server-side checks pass but SSH still fails from client, the issue is network firewall or ISP blocking.
Testing order: Always test from simple (ping) to complex (SSH). If SSH fails but ping and nc work, the issue is application-level. If nc times out, it's network-level before SSH.
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