How to fix Disconnected from authenticating user root hostname port XXXXX [preauth] in SSH

SSHINTERMEDIATEMEDIUMUpdated Apr 27, 2026· 414 views

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.

Quick fix

Fixes Disconnected from authenticating user root hostname port XXXXX [preauth]

# 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 -f
  1. Check SSH server logs for detailed error messages
  2. Verify your SSH client is using compatible authentication methods
  3. If legitimate users cannot connect, check SSH key configuration
  4. For excessive preauth disconnections from external IPs, use fail2ban
ssh — error
# 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 -f
Disconnected from authenticating user root hostname port XXXXX [preauth]

What this error means

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.

Typical symptoms

  • SSH connection attempts fail with immediate disconnection
  • Repeated "Disconnected from authenticating user" messages in /var/log/auth.log or /var/log/secure
  • Connection closes before password or key prompt appears
  • Multiple failed authentication attempts from external IP addresses
  • Slow SSH login followed by sudden disconnection

Common causes

  1. Too many failed authentication attempts exceeded MaxAuthTries limit (default 6, per-connection)
  2. Brute-force attack or automated bot attempt using wrong credentials
  3. SSH key type mismatch - client using deprecated key type (e.g., RSA) not in PubkeyAcceptedAlgorithms
  4. Cipher or MAC algorithm mismatch between client and server
  5. Client offering too many SSH keys causing authentication retry limit to be exceeded
  6. Network firewall or DPI system closing connection before auth completes

How to fix "Disconnected from authenticating user root hostname port XXXXX [preauth]"

1Check SSH server logs for detailed error messages

Review your SSH daemon logs to identify the specific cause of disconnection:

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

Look 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

2Verify your SSH client is using compatible authentication methods

If you're connecting to this server, check that your client supports the server's authentication methods. Test with verbose output:

bash
# Show detailed debugging information
ssh -vvv user@hostname

Look 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.

3If legitimate users cannot connect, check SSH key configuration

Verify the authorized_keys file has correct permissions and location:

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

Default location is ~/.ssh/authorized_keys. Permissions must be 700 for .ssh and 600 for authorized_keys, or SSH will reject the key authentication.

4For excessive preauth disconnections from external IPs, use fail2ban

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:

bash
# Install fail2ban
sudo apt-get install fail2ban

# Create local SSH jail config
sudo nano /etc/fail2ban/jail.local

Add configuration:

ini
[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 5
findtime = 600
bantime = 3600

This bans IPs after 5 failed attempts within 10 minutes for 1 hour.

5Increase MaxAuthTries if legitimate clients are hitting the limit

If your SSH client is offering multiple keys and hitting the connection retry limit, increase the limit on the server:

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

Find and modify:

bash
MaxAuthTries 10

Default is 6. This allows clients to try more authentication methods before disconnecting. Then restart SSH:

bash
sudo systemctl restart sshd
6Verify SSH daemon is running and listening correctly

Ensure the SSH server is running and listening on the expected port:

bash
# Check if SSH is running
sudo systemctl status sshd

# Verify SSH is listening
sudo netstat -tlnp | grep sshd
# or
sudo ss -tlnp | grep sshd

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

bash
sudo systemctl restart sshd

Advanced notes

The 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.

Frequently asked questions

What does "Disconnected from authenticating user root hostname port XXXXX [preaut" mean?
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.
How do I fix "Disconnected from authenticating user root hostname port XXXXX [preaut"?
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.
What causes "Disconnected from authenticating user root hostname port XXXXX [preaut"?
Too many failed authentication attempts exceeded MaxAuthTries limit (default 6, per-connection) Brute-force attack or automated bot attempt using wrong credentials SSH key type mismatch - client using deprecated key type (e.g., RSA) not in PubkeyAcceptedAlgorithms
Is the "Disconnected from authenticating user root hostname port XXXXX [preaut" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading