This error occurs when the SSH server on a remote host unexpectedly closes the connection after accepting the TCP connection but before or immediately after authentication. It usually indicates server-side configuration issues, resource constraints, or authentication failures rather than network problems.
When you connect to an SSH server, the TCP connection establishes successfully (the server accepts the socket connection). However, the SSH server then closes the connection before completing the authentication handshake or immediately after it. This is different from a connection timeout or refused connection—the server actively terminates an already-open socket. This typically happens when the SSH daemon (sshd) detects a configuration issue, authentication failure, or resource constraint.
Use SSH verbose flags to see detailed connection logs:
ssh -vvv user@hostnameThe three -v flags produce maximum verbosity. Look for where the output stops—this shows exactly when the server closes the connection. Common indicators:
- "Server version" = TCP accepted, negotiation started
- "Offering public key" = SSH handshake started but server rejected auth
- Nothing after key offer = server closed after seeing key offer
SSH server logs reveal the exact reason for closure. If you can access the server another way (physical console, different SSH account, cloud console), check:
# Debian/Ubuntu
sudo tail -50 /var/log/auth.log | grep sshd
# RHEL/CentOS/Fedora
sudo tail -50 /var/log/secure | grep sshd
# Modern systemd systems
sudo journalctl -u ssh -n 50
sudo journalctl -u sshd -n 50Look for messages like:
- "Too many authentication failures"
- "MaxSessions exceeded"
- "Invalid user"
- "Received disconnect"
- "Fatal: no more authentication methods available"
If the server banned you due to too many failed attempts, it may have a temporary ban. Wait 5-10 minutes (default fail2ban unban time) or restart the SSH daemon:
If you have access via another method:
# Restart SSH daemon (choose one based on your system)
sudo systemctl restart ssh # Ubuntu/Debian
sudo systemctl restart sshd # RHEL/CentOS/Fedora
sudo service ssh restart # Older Debian/Ubuntu
sudo service sshd restart # Older RHEL/CentOSThen try connecting again from a different IP if possible.
Ensure you're using the correct username for the system and supported authentication method:
# Try with explicit username
ssh -u ubuntu@hostname # Ubuntu AMIs use 'ubuntu'
ssh -u ec2-user@hostname # Amazon Linux uses 'ec2-user'
ssh -u root@hostname # Some images use 'root'
ssh -u centos@hostname # CentOS uses 'centos'
# Try with explicit key
ssh -i ~/.ssh/key.pem user@hostname
# Try with password (if key auth fails)
ssh -o PubkeyAuthentication=no user@hostnameIf none work, the account may be disabled or the authentication method is rejected by server configuration.
Verify the SSH daemon is running and listening on the expected port (default 22):
If you have access to the server:
# Check if sshd is running
sudo systemctl status ssh # or sshd on RHEL
# Check what ports SSH is listening on
sudo ss -tlnp | grep ssh
sudo netstat -tlnp | grep sshExpected output should show sshd listening on 0.0.0.0:22 or [::]:22
If not running, start it:
sudo systemctl start ssh # Ubuntu/Debian
sudo systemctl start sshd # RHEL/CentOSCheck if the server configuration restricts your access:
# Review key SSH settings that might block you
sudo grep -E "^(AllowUsers|DenyUsers|PermitRootLogin|MaxAuthTries|MaxSessions)" /etc/ssh/sshd_configCommon issues:
- AllowUsers user1 user2 — Your username not in list
- DenyUsers user — Your username explicitly blocked
- PermitRootLogin no — Root login disabled but you're trying as root
- MaxAuthTries 2 — Very low limit, you've exceeded it
Fix by editing /etc/ssh/sshd_config with proper permissions, then restart SSH:
sudo nano /etc/ssh/sshd_config
sudo systemctl restart sshIf the server is out of resources, SSH may close the connection:
Check from server console or if you can access another way:
# Disk space
df -h
# Memory
free -h
# Check for OOM (Out of Memory) errors
sudo dmesg | tail -20If disk is full (100%), you cannot log in via SSH. Free space:
# Find large files
du -sh /*
rm -rf /tmp/* # Remove temp filesIf memory is exhausted, restart the system or kill memory-hungry processes.
If you suspect Fail2Ban or firewall blocking, try from a different network:
# From a different computer or through a VPN
ssh -v user@hostname
# Or use a web-based console if available (AWS/Azure/GCP)
# This bypasses network restrictionsIf the connection works from another IP, you're likely banned by Fail2Ban or firewall rules. Access the server via console and check:
# Check Fail2Ban status
sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip YOUR_IPAdvanced troubleshooting:
Fail2Ban Bans: If you've failed authentication multiple times in short succession, Fail2Ban may temporarily ban your IP. Check status:
sudo fail2ban-client status sshd
# Shows banned IPs and ban durationsTo permanently unban:
sudo fail2ban-client set sshd unbanip YOUR.IP.ADDRESSSSH Key Format Compatibility: Very old SSH servers (pre-2016) may not support newer key types like ed25519. Try generating an older RSA key:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/old_keySELinux Blocking: On RHEL/CentOS with SELinux enabled, SSH may be blocked by policy:
getenforce # Shows SELinux status
# Check SSH contexts in auditd logs
sudo grep sshd /var/log/audit/audit.log | tail -20SSH Reverse Tunnel Issues: If you're using SSH reverse tunnels or port forwarding, the remote SSH server may close if the tunnel attempt fails. Test basic connectivity first without tunneling.
Cloud Provider SSH Issues: AWS, Azure, GCP sometimes delay SSH readiness after instance launch. Wait 1-2 minutes after launch before first SSH attempt. Use instance metadata console to test if networking is ready.
Very Old OpenSSH Versions: If the server runs OpenSSH < 7.0 (released 2015), you may need legacy algorithms enabled:
ssh -o PubkeyAcceptedKeyTypes=+ssh-rsa [email protected]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