Fix SSH Connection Refused and Timeout Errors in Linux

By Tech Writer Linux
Complete guide to troubleshooting SSH connection problems. Learn how to fix connection refused, timeout, and authentication errors.

Understanding SSH Connection Errors

SSH (Secure Shell) is essential for remote server management, but connection issues can be frustrating. This guide covers the most common SSH problems and their solutions.

Common SSH Error Messages

  • Connection refused - SSH service not running or wrong port
  • Connection timeout - Firewall blocking or network issue
  • Permission denied - Authentication failed
  • Host key verification failed - Server key changed
  • Too many authentication failures - Multiple key attempts

Fix: Connection Refused

Check if SSH Service is Running

# Check SSH status
sudo systemctl status sshd
# or on some systems
sudo systemctl status ssh

# Start SSH service
sudo systemctl start sshd

# Enable SSH on boot
sudo systemctl enable sshd

Verify SSH is Listening on Port

# Check listening ports
sudo ss -tulpn | grep :22
sudo netstat -tulpn | grep :22

# Check SSH configuration
sudo grep ^Port /etc/ssh/sshd_config

Fix SSH Configuration

# Edit SSH config
sudo nano /etc/ssh/sshd_config

# Ensure these settings:
Port 22
PermitRootLogin yes  # or prohibit-password
PasswordAuthentication yes  # if using passwords

# Restart SSH after changes
sudo systemctl restart sshd

Fix: Connection Timeout

Check Firewall Rules

# UFW (Ubuntu)
sudo ufw allow 22/tcp
sudo ufw allow ssh
sudo ufw reload

# firewalld (CentOS/RHEL)
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

# iptables
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -L -n

Check if Server is Reachable

# Test connectivity
ping server_ip

# Check if port 22 is open
telnet server_ip 22
nc -zv server_ip 22

# Traceroute to server
traceroute server_ip

Cloud Provider Security Groups

For AWS, Azure, GCP, DigitalOcean:

  • Check security group rules allow port 22
  • Verify network ACLs permit SSH traffic
  • Ensure instance has public IP (if connecting from internet)

Fix: Permission Denied (Key Authentication)

Verify Key Permissions

# Correct permissions for SSH keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 644 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts

Check Key is Being Used

# Test SSH with verbose output
ssh -v user@server

# Specify key explicitly
ssh -i ~/.ssh/id_rsa user@server

# Test key authentication
ssh -T git@github.com  # For GitHub

Server-Side Key Setup

# On server, check authorized_keys
cat ~/.ssh/authorized_keys

# Verify ownership
ls -la ~/.ssh/
# Should be owned by your user

# Fix ownership if needed
sudo chown -R owner:owner ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Fix: Permission Denied (Password Authentication)

Enable Password Authentication

# Edit SSH config on server
sudo nano /etc/ssh/sshd_config

# Change or add:
PasswordAuthentication yes
ChallengeResponseAuthentication yes
UsePAM yes

# Restart SSH
sudo systemctl restart sshd

Reset User Password

# Reset password (as root or sudo user)
sudo passwd username

Fix: Host Key Verification Failed

Error message: WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

# Remove old host key (if you trust the new one)
ssh-keygen -R server_hostname_or_ip

# Or edit known_hosts directly
nano ~/.ssh/known_hosts
# Remove the offending line

# Connect again (will add new key)
ssh user@server

Fix: Too Many Authentication Failures

# Connect with specific key only
ssh -o IdentitiesOnly=yes -i ~/.ssh/specific_key user@server

# Or configure in ~/.ssh/config
Host myserver
    HostName server.com
    User username
    IdentityFile ~/.ssh/specific_key
    IdentitiesOnly yes

Advanced SSH Configuration

SSH Client Configuration (~/.ssh/config)

# Create config file
nano ~/.ssh/config

# Add host configurations
Host myserver
    HostName 192.168.1.100
    User admin
    Port 22
    IdentityFile ~/.ssh/id_rsa
    ServerAliveInterval 60
    ServerAliveCountMax 3

Host *
    ServerAliveInterval 60
    TCPKeepAlive yes

Useful SSH Options

# Disable host key checking (DANGEROUS - use only for testing)
ssh -o StrictHostKeyChecking=no user@server

# Use different port
ssh -p 2222 user@server

# Enable compression
ssh -C user@server

# Keep connection alive
ssh -o ServerAliveInterval=60 user@server

Debugging SSH Issues

Verbose SSH Output

# Increasing verbosity levels
ssh -v user@server   # Verbose
ssh -vv user@server  # More verbose
ssh -vvv user@server # Debug level

Check SSH Logs

# On server, check authentication logs
sudo tail -f /var/log/auth.log      # Ubuntu/Debian
sudo tail -f /var/log/secure        # CentOS/RHEL
sudo journalctl -u sshd -f          # systemd systems

Security Best Practices

  1. Disable root login: PermitRootLogin no
  2. Use key authentication: Disable password auth when possible
  3. Change default port: Use non-standard port (e.g., 2222)
  4. Use fail2ban: Automatically block brute force attempts
  5. Limit user access: AllowUsers username in sshd_config
  6. Keep SSH updated: sudo apt update && sudo apt upgrade openssh-server

Install and Configure fail2ban

# Install fail2ban
sudo apt install fail2ban

# Configure for SSH
sudo nano /etc/fail2ban/jail.local

# Add:
[sshd]
enabled = true
port = 22
maxretry = 3
bantime = 3600

# Start fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Quick Troubleshooting Checklist

  1. Is SSH service running? sudo systemctl status sshd
  2. Is the firewall allowing port 22? sudo ufw status
  3. Can you ping the server? ping server_ip
  4. Is port 22 open? nc -zv server_ip 22
  5. Are SSH key permissions correct? ls -la ~/.ssh/
  6. What do SSH logs show? sudo tail /var/log/auth.log
  7. Try verbose mode: ssh -vvv user@server

Conclusion

Most SSH connection issues fall into one of these categories: service not running, firewall blocking, authentication problems, or network connectivity. By following the systematic troubleshooting steps in this guide, you can quickly identify and resolve SSH connection problems.

Remember to always keep SSH security best practices in mind, even when troubleshooting - never leave your system vulnerable just to get a connection working.