This SSH error indicates the server closed the connection before authentication completed. Common causes include too many failed login attempts, authentication method mismatches, or failed brute-force attacks.
The "[preauth]" tag in sshd logs indicates a connection terminated before the authentication phase completed. This happens when the SSH server closes the connection during the pre-authentication stage, before the user has successfully provided valid credentials. The message shows which user account was being authenticated and from which IP address and port the connection originated. This is a normal part of SSH security logging and can result from legitimate connection issues, authentication failures, or automated brute-force attacks.
Review your SSH daemon logs to identify the specific cause of disconnection:
# On Linux systems
sudo tail -f /var/log/auth.log
# Or on some systems
sudo tail -f /var/log/secure
# Or using journalctl
sudo journalctl -u ssh -fLook for specific error messages like:
- "Too many authentication failures" → auth retry limit reached
- "no matching cipher found" → cipher mismatch
- "no matching mac found" → MAC algorithm mismatch
- "key type ssh-rsa not in PubkeyAcceptedAlgorithms" → unsupported key type
If you're connecting to this server, check that your client supports the server's authentication methods. Test with verbose output:
# Show detailed debugging information
ssh -vvv user@hostnameLook for lines showing negotiated algorithms. If you see "key type ssh-rsa not accepted", you're using an old RSA key and the server doesn't accept it. Modern OpenSSH (7.2+) disabled weak ciphers and MACs for security.
Verify the authorized_keys file has correct permissions and location:
# Fix permissions on .ssh directory
chmod 700 ~/.ssh
# Fix permissions on authorized_keys file
chmod 600 ~/.ssh/authorized_keys
# Verify authorized_keys location in sshd_config
grep AuthorizedKeysFile /etc/ssh/sshd_configDefault location is ~/.ssh/authorized_keys. Permissions must be 700 for .ssh and 600 for authorized_keys, or SSH will reject the key authentication.
If your logs show many "Disconnected from authenticating user" entries from random IPs, this is typically brute-force attacks. Use fail2ban to block attacking IPs:
# Install fail2ban
sudo apt-get install fail2ban
# Create local SSH jail config
sudo nano /etc/fail2ban/jail.localAdd configuration:
[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 5
findtime = 600
bantime = 3600This bans IPs after 5 failed attempts within 10 minutes for 1 hour.
If your SSH client is offering multiple keys and hitting the connection retry limit, increase the limit on the server:
# Edit SSH server config
sudo nano /etc/ssh/sshd_configFind and modify:
MaxAuthTries 10Default is 6. This allows clients to try more authentication methods before disconnecting. Then restart SSH:
sudo systemctl restart sshdEnsure the SSH server is running and listening on the expected port:
# Check if SSH is running
sudo systemctl status sshd
# Verify SSH is listening
sudo netstat -tlnp | grep sshd
# or
sudo ss -tlnp | grep sshdYou should see output like tcp 0 0 0.0.0.0:22 indicating SSH is listening on port 22. If SSH is not running, restart it:
sudo systemctl restart sshdThe preauth disconnection is a normal part of SSH security logging. High volumes of "Disconnected from authenticating user root" messages are usually not a concern—they indicate failed login attempts, not successful breaches. This is why it's normal to see many such messages, especially on internet-facing servers.
Modern OpenSSH versions (7.2+) removed weak ciphers (DES, 3DES, RC4) and deprecated RSA SHA1 signatures for security. If you're using old SSH clients or third-party SFTP clients (like WinSCP or Cyberduck), they may not support the server's algorithms. For compatibility, you may need to explicitly enable legacy algorithms in sshd_config using "Ciphers +3des-cbc" or similar, though this reduces security.
If your home directory is encrypted (e.g., eCryptfs), sshd may not be able to read ~/.ssh/authorized_keys on login. In that case, move authorized_keys to /etc/ssh/authorized_keys/{username} and update AuthorizedKeysFile in sshd_config to point there.
Load key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH
Connection closed by UNKNOWN port 65535
How to fix 'Connection closed by UNKNOWN port 65535' in SSH
Offending ECDSA key in /home/user/.ssh/known_hosts:line
How to fix "Offending ECDSA key in known_hosts" in SSH