SSH Troubleshooting Guide 2026: Fix Connection, Permission & Timeout Issues

Updated 2026-08-15

SSH fails for 5 reasons (in order of frequency):

1. Wrong key permissions (authorized_keys is world-readable or wrong ownership) → Fix: chmod 600 ~/.ssh/authorized_keys && chmod 700 ~/.ssh
2. SSH daemon isn’t running → Fix: sudo systemctl start ssh (Ubuntu/Debian) or sudo systemctl start sshd (RedHat/CentOS)
3. Firewall blocking port 22 → Fix: sudo ufw allow 22 or check security group in cloud console
4. Wrong key or username → Fix: ssh -v user@host to verify auth method attempts
5. SSH service config issue (/etc/ssh/sshd_config) → Fix: sudo sshd -t to validate syntax, then sudo systemctl restart ssh

This guide walks through diagnosing and fixing each.

SSH Basics (2026 Reality)

What is SSH?

SSH (Secure Shell) is the encrypted protocol for remote server access. Replaces telnet (insecure).

# Basic SSH connection
ssh user@example.com

# SSH to non-standard port
ssh -p 2222 user@example.com

# Execute command and return
ssh user@example.com "ls -la"

# Copy file via SCP (Secure Copy)
scp file.txt user@example.com:/tmp/

Key Authentication (2026 Best Practice)

Password auth is deprecated. Use SSH keys:

# Generate 4096-bit RSA key (old, still works)
ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa

# Generate Ed25519 key (2026 modern, recommended)
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

Public key (~/.ssh/id_ed25519.pub) → Goes on server
Private key (~/.ssh/id_ed25519) → Stays on your laptop, never shared

SSH Failure Modes: Diagnosis & Fix

Error 1: “Permission denied (publickey)”

You see:

Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Root Causes (in order)

1A: Key Permissions Wrong on Server

Diagnosis:

# SSH to server with password (if enabled) or via recovery console
ssh user@example.com

# Check permissions
ls -la ~/.ssh/
ls -la ~/.ssh/authorized_keys

Expected output

drwx------  2 user user 4096 Aug 15 10:00 .ssh
-rw-------  1 user user  400 Aug 15 09:50 authorized_keys

If wrong, you see:

drwxrwxr-x  ← WRONG! Group/world-writable directory
-rw-rw-r--  ← WRONG! Group-writable file

Fix:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Why it matters: with StrictModes on (the default), sshd refuses to use authorized_keys if it, the .ssh directory, or the home directory is writable by anyone other than the owner. Group- or world-readable permissions on their own don’t trigger the rejection; group- or world-writable ones do. A readable private key, not a readable authorized_keys, is the actual compromised-credentials case.

1B: Public Key Not in authorized_keys

Diagnosis:

# On your laptop, find your public key
cat ~/.ssh/id_ed25519.pub
# Output: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBxzF... user@laptop

# On server, check if it's listed
cat ~/.ssh/authorized_keys

If your key isn’t there, add it:

# From laptop, copy your public key to server
cat ~/.ssh/id_ed25519.pub | ssh user@example.com "cat >> ~/.ssh/authorized_keys"

# Or manually SSH in and paste:
ssh user@example.com
# Paste: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBxzF... user@laptop
cat >> ~/.ssh/authorized_keys
# Press Ctrl+D

1C: Wrong Key File Path

Diagnosis:

# Check if SSH is looking for the right key
ssh -v user@example.com 2>&1 | grep -i "key\|identity"

Output shows something like

Trying private key /home/user/.ssh/id_rsa
No more authentication methods to try.

If you generated id_ed25519 but SSH is looking for id_rsa, specify it:

ssh -i ~/.ssh/id_ed25519 user@example.com

Or configure permanently in ~/.ssh/config:

Host example.com
  User user
  IdentityFile ~/.ssh/id_ed25519
  Port 22

1D: SSH Daemon Rejecting Key Auth (sshd_config)

Diagnosis:

ssh -v user@example.com 2>&1 | grep -i "key"
# If you see: "Server refused our key", check server config

Fix (on server)

sudo nano /etc/ssh/sshd_config

# Ensure these lines exist (uncommented):
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Then restart SSH:

sudo systemctl restart ssh  # Ubuntu/Debian
sudo systemctl restart sshd # CentOS/RedHat

Error 2: “Connection refused”

You see:

ssh: connect to host example.com port 22: Connection refused

Root Causes:

2A: SSH Daemon Not Running

Diagnosis:

# Try to connect with verbose output
ssh -v user@example.com 2>&1 | head -20
# Shows: "Connection refused" immediately (not "Connection reset")

Fix:

# If you have server access via console/RDP/recovery:
sudo systemctl start ssh      # Ubuntu/Debian
sudo systemctl start sshd     # CentOS/RedHat
sudo service ssh start        # Older systems

# Verify it's running:
sudo systemctl status ssh
sudo netstat -tlnp | grep :22  # Port 22 listening?

2B: SSH Listening on Different Port

Diagnosis:

sudo netstat -tlnp | grep ssh
# Output shows: tcp 0 0 0.0.0.0:2222 LISTEN

If SSH is on port 2222 (not default 22):

ssh -p 2222 user@example.com

Error 3: “Connection timed out”

You see:

ssh: connect to host example.com port 22: Connection timed out

Unlike “Connection refused”, SSH is stuck (not instant rejection). Firewall or network issue.

Root Causes:

3A: Firewall Blocking Port 22

Diagnosis:

# Try from another network (if possible)
# Or check firewall logs on server:
sudo iptables -L -n | grep 22
sudo ufw status  # If using UFW

Fix:

# Ubuntu/Debian UFW:
sudo ufw allow 22/tcp
sudo ufw allow ssh  # Alternative

# CentOS/RedHat firewalld:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

# Raw iptables (dangerous, prefer ufw):
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

3B: Cloud Security Group Blocking

If server is on AWS/Azure/GCP:

1. Go to your cloud console
2. Find the server’s security group / network security group
3. Add inbound rule: Protocol: TCP, Port: 22, Source: Your IP (or 0.0.0.0/0 for testing)

AWS Example

Inbound Rules:
Protocol: TCP
Port Range: 22
Source: 0.0.0.0/0 (or your specific IP)

3C: Network Path Unreachable

Diagnosis:

# Test connectivity to the server IP
ping example.com  # Works? Host is up.
traceroute example.com  # Where does it timeout?

If ping times out:

• DNS issue? nslookup example.com should resolve to an IP
• Network down? Try from a different network (mobile hotspot)
• Wrong IP address? Double-check hostname resolves correctly

Error 4: “Host key verification failed”

You see:

Host key verification failed.

Root Cause: SSH doesn’t recognize the server’s fingerprint (first-time connection or server key changed).

Diagnosis & Fix

# First connection should prompt:
# Are you sure you want to continue connecting (yes/no)?
yes

# Accept the key, it's added to ~/.ssh/known_hosts

# If you get "Host key verification failed" without prompt:
# (automation/script issue), add server to known_hosts manually:

ssh-keyscan -t ed25519 example.com >> ~/.ssh/known_hosts 2>/dev/null

If server key changed (security incident or server rebuild):

# Remove old key
ssh-keygen -R example.com

# Reconnect (will prompt again)
ssh user@example.com

Error 5: “Too many authentication failures”

You see:

Received disconnect from 1.2.3.4: Too many authentication failures for user

Root Cause: Your SSH agent is offering more keys than the server’s MaxAuthTries allows, so the server disconnects before it ever reaches the correct one. This isn’t a lockout or rate limit, so waiting doesn’t fix it.

Fix:

# Tell SSH to try only the key you specify, not every key the agent offers:
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@example.com

Prevent this in ~/.ssh/config

Host example.com
  User user
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes  # ← Only try this key, not all keys

Advanced Debugging: -v Flag

The -v (verbose) flag shows SSH’s decision-making step-by-step:

ssh -v user@example.com 2>&1 | head -50

Read these lines carefully

1. “Trying private key…”: Which keys is SSH attempting?
2. “Authentications that can continue: publickey, password”: Server allowing which methods?
3. “Server refused our key”: Your key was rejected; check permissions/authorized_keys
4. “Connection refused”: SSH daemon not listening
5. “No more authentication methods”: Exhausted all options; wrong key or not in authorized_keys

For extreme debugging

ssh -vvv user@example.com  # Triple verbose (packet-level)

SSH Server Configuration (/etc/ssh/sshd_config) 2026 Best Practices

# Backup original
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup

# Edit
sudo nano /etc/ssh/sshd_config

Recommended 2026 settings

# Authentication
PubkeyAuthentication yes
PasswordAuthentication no      # ← Disable passwords, use keys only
PermitRootLogin no             # ← Never allow root SSH
MaxAuthTries 3                 # ← Reduce brute-force attempts
MaxSessions 5

# Security
Port 22                        # ← Change to 2222 if you want obscurity
AllowUsers user1 user2         # ← Whitelist users

# Ciphers (modern)
KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512
Ciphers chacha20-poly1305@openssh.com,aes-256-gcm@openssh.com
MACs hmac-sha2-512,hmac-sha2-512-etm@openssh.com

# Logging
SyslogFacility AUTH
LogLevel VERBOSE

Validate config syntax

sudo sshd -t  # Returns 0 if OK

Restart SSH

sudo systemctl restart ssh

SSH Checklist (Troubleshooting Order)

□ 1. Verify SSH daemon running:
      sudo systemctl status ssh

□ 2. Check port 22 open:
      sudo netstat -tlnp | grep :22

□ 3. Firewall rule exists:
      sudo ufw status | grep 22

□ 4. ~/.ssh/authorized_keys has your public key:
      cat ~/.ssh/authorized_keys | grep "$(cat ~/.ssh/id_ed25519.pub)"

□ 5. File permissions correct:
      ls -la ~/.ssh → must be 700
      ls -la ~/.ssh/authorized_keys → must be 600

□ 6. SSH config allows public key auth:
      grep "^PubkeyAuthentication" /etc/ssh/sshd_config → yes

□ 7. Network connectivity:
      ping example.com
      telnet example.com 22

□ 8. Run verbose SSH:
      ssh -v user@example.com 2>&1 | head -50

Rapid-Fire Solutions

2026 SSH Best Practices

1. Use Ed25519 keys (faster, more secure than RSA)
2. Disable password authentication (PasswordAuthentication no)
3. Never SSH as root (dedicated user, sudo for elevation)
4. Use SSH keys, not passwords (can’t brute-force a key)
5. Firewall to your IP only (not 0.0.0.0/0 unless testing)
6. Rotate keys annually (generate new pair, remove old)
7. Use SSH agent (ssh-add) to avoid typing passphrase repeatedly

Affiliate Links & Resources

• SSH Key Generator: Built into every modern OS (Windows 10+, macOS, Linux)
• SSH Reference: OpenSSH Manual
• PuTTY SSH Client (Windows): Download

Last updated: August 15, 2026