How to fix Connection to hostname closed by remote host. in SSH

SSHINTERMEDIATEHIGHUpdated Jan 4, 2026· 295 views

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.

Quick fix

Fixes Connection to hostname closed by remote host.

ssh -vvv user@hostname
  1. Connect with verbose mode to see exactly where connection closes
  2. Check SSH server logs on the remote host
  3. Reset failed authentication attempts with a delay
  4. Verify your username and authentication method
ssh — error
ssh -vvv user@hostname
Connection to hostname closed by remote host.

What this error means

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.

Typical symptoms

  • Connection appears to establish then closes without prompting for password
  • SSH command returns 'Connection closed' or 'Connection closed by remote host' immediately
  • No authentication prompt appears (password or key challenge)
  • Error message appears after 'Offering public key' in verbose mode
  • Manual attempts to SSH always fail at the same point
  • Other users or different authentication methods also fail

Common causes

  1. Too many failed authentication attempts (MaxAuthTries exceeded), server bans new attempts
  2. SSH server reached MaxSessions limit and cannot accept new connections
  3. User account is locked, disabled, or shell is set to /usr/sbin/nologin
  4. Firewall rule or TCP wrapper blocking the connection (even though TCP succeeds, firewall may close after accepting)
  5. SSH server configuration issue (e.g., invalid PermitRootLogin setting, broken sshd_config)
  6. Server is out of memory or disk space and cannot allocate resources for session
  7. SSH daemon crash or restart during connection attempt
  8. SSH key format incompatible with server (e.g., old OpenSSH version not supporting modern key types)
  9. Fail2Ban or similar rate limiting tool temporarily banning the client IP
  10. Incorrect SSH port specified (connected to different service that closes immediately)

How to fix "Connection to hostname closed by remote host."

1Connect with verbose mode to see exactly where connection closes

Use SSH verbose flags to see detailed connection logs:

bash
ssh -vvv user@hostname

The 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

2Check SSH server logs on the remote host

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:

bash
# 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 50

Look for messages like:
- "Too many authentication failures"
- "MaxSessions exceeded"
- "Invalid user"
- "Received disconnect"
- "Fatal: no more authentication methods available"

3Reset failed authentication attempts with a delay

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:

bash
# 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/CentOS

Then try connecting again from a different IP if possible.

4Verify your username and authentication method

Ensure you're using the correct username for the system and supported authentication method:

bash
# 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@hostname

If none work, the account may be disabled or the authentication method is rejected by server configuration.

5Check SSH server is actually running

Verify the SSH daemon is running and listening on the expected port (default 22):

If you have access to the server:

bash
# 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 ssh

Expected output should show sshd listening on 0.0.0.0:22 or [::]:22

If not running, start it:

bash
sudo systemctl start ssh      # Ubuntu/Debian
sudo systemctl start sshd     # RHEL/CentOS
6Review SSH server configuration for restrictions

Check if the server configuration restricts your access:

bash
# Review key SSH settings that might block you
sudo grep -E "^(AllowUsers|DenyUsers|PermitRootLogin|MaxAuthTries|MaxSessions)" /etc/ssh/sshd_config

Common 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:

bash
sudo nano /etc/ssh/sshd_config
sudo systemctl restart ssh
7Check disk space and server resources

If the server is out of resources, SSH may close the connection:

Check from server console or if you can access another way:

bash
# Disk space
df -h

# Memory
free -h

# Check for OOM (Out of Memory) errors
sudo dmesg | tail -20

If disk is full (100%), you cannot log in via SSH. Free space:

bash
# Find large files
du -sh /*
rm -rf /tmp/*  # Remove temp files

If memory is exhausted, restart the system or kill memory-hungry processes.

8Try connecting from a different IP or client

If you suspect Fail2Ban or firewall blocking, try from a different network:

bash
# 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 restrictions

If the connection works from another IP, you're likely banned by Fail2Ban or firewall rules. Access the server via console and check:

bash
# Check Fail2Ban status
sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip YOUR_IP

Advanced notes

Advanced troubleshooting:

Fail2Ban Bans: If you've failed authentication multiple times in short succession, Fail2Ban may temporarily ban your IP. Check status:

bash
sudo fail2ban-client status sshd
# Shows banned IPs and ban durations

To permanently unban:

bash
sudo fail2ban-client set sshd unbanip YOUR.IP.ADDRESS

SSH Key Format Compatibility: Very old SSH servers (pre-2016) may not support newer key types like ed25519. Try generating an older RSA key:

bash
ssh-keygen -t rsa -b 4096 -f ~/.ssh/old_key

SELinux Blocking: On RHEL/CentOS with SELinux enabled, SSH may be blocked by policy:

bash
getenforce  # Shows SELinux status
# Check SSH contexts in auditd logs
sudo grep sshd /var/log/audit/audit.log | tail -20

SSH 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:

bash
ssh -o PubkeyAcceptedKeyTypes=+ssh-rsa user@old-server.com

Frequently asked questions

What does "Connection to hostname closed by remote host." mean?
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.
How do I fix "Connection to hostname closed by remote host."?
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.
What causes "Connection to hostname closed by remote host."?
Too many failed authentication attempts (MaxAuthTries exceeded), server bans new attempts SSH server reached MaxSessions limit and cannot accept new connections User account is locked, disabled, or shell is set to /usr/sbin/nologin
Is the "Connection to hostname closed by remote host." error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading