How to fix Connection reset by hostname port XXXXX [preauth] in SSH

SSHINTERMEDIATEMEDIUMUpdated Jan 4, 2026· 360 views

The SSH server resets the TCP connection before authentication completes. This usually stems from network issues, brute-force attempts, or client timeout during key exchange.

Quick fix

Fixes Connection reset by hostname port XXXXX [preauth]

sudo systemctl stop sshd
sudo sshd -dd
  1. Check SSH server logs for patterns
  2. Enable SSH server debug mode for detailed diagnostics
  3. Verify sshd_config authentication settings
  4. Disable GSSAPI and DNS lookups if causing delays
ssh — error
sudo systemctl stop sshd
sudo sshd -dd
Connection reset by hostname port XXXXX [preauth]

What this error means

The "[preauth]" tag indicates the connection was terminated before the authentication phase began. This commonly happens during the key exchange or initial protocol negotiation. The reset can originate from either the client dropping the connection unexpectedly or network hardware issues (firewalls, switches) forcing a TCP reset packet.

Typical symptoms

  • SSH connection attempts suddenly drop without clear error message
  • Connection works intermittently from some clients but not others
  • Server logs show repeated "Connection reset" entries from brute-force attacks
  • tcpdump shows RST packets with no window or IP ID set
  • systemd socket-activated SSH has issues with concurrent connections

Common causes

  1. Brute-force attack attempts triggering connection limits
  2. Network hardware (switch, firewall) sending unsolicited RST packets
  3. Client timeout during key exchange negotiation
  4. Multiple simultaneous connections (e.g., IPv6 ::1 and IPv4 127.0.0.1) overwhelming the server
  5. SSH server crash or hang during pre-authentication phase
  6. Deprecated or mismatched SSH key types between client and server
  7. Firewall rules or intrusion detection blocking the connection

How to fix "Connection reset by hostname port XXXXX [preauth]"

1Check SSH server logs for patterns

Run "tail -f /var/log/auth.log" or "journalctl -u sshd -f" on the server to monitor incoming connections and identify if the resets correlate with brute-force attempts or legitimate clients.

Look for patterns:
- Multiple failed password attempts from the same IP
- "Connection reset" entries in rapid succession
- Specific client IPs consistently triggering the error

2Enable SSH server debug mode for detailed diagnostics

Stop the running SSH server and run it in debug mode to capture detailed connection information:

bash
sudo systemctl stop sshd
sudo sshd -dd

In another terminal, attempt a connection:

bash
ssh -vvv user@target-host

Debug output will show exactly where the connection breaks (key exchange, authentication, etc.). Stop with Ctrl+C when done.

Restart SSH normally:

bash
sudo systemctl start sshd
3Verify sshd_config authentication settings

Edit /etc/ssh/sshd_config and ensure essential options are configured:

bash
sudo nano /etc/ssh/sshd_config

Key settings to check:
- LoginGraceTime 120 (grace period for auth before reset)
- MaxAuthTries 6 (max failed attempts)
- PubkeyAuthentication yes (enable key auth)
- PasswordAuthentication yes (enable password auth, if needed)
- AuthorizedKeysFile .ssh/authorized_keys (correct path)

After editing, validate the config:

bash
sudo sshd -t

If valid, restart SSH:

bash
sudo systemctl restart sshd
4Disable GSSAPI and DNS lookups if causing delays

Slow DNS or GSSAPI authentication can timeout during preauth. Edit /etc/ssh/sshd_config:

bash
GSSAPIAuthentication no
UseDNS no

These settings prevent the server from performing reverse DNS lookups or attempting Kerberos authentication, both of which can cause timeouts.

Validate and restart:

bash
sudo sshd -t && sudo systemctl restart sshd
5Check for brute-force attacks and configure fail2ban

If logs show repeated "Connection reset" from specific IPs, install and configure fail2ban to block attackers:

bash
sudo apt-get install fail2ban
sudo systemctl start fail2ban

Create /etc/fail2ban/jail.local:

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

Restart fail2ban:

bash
sudo systemctl restart fail2ban

View currently banned IPs:

bash
sudo fail2ban-client status sshd
6Verify network connectivity and capture packets if needed

Use tcpdump to inspect the actual network traffic:

bash
sudo tcpdump -i eth0 -n host <client-ip> and port 22

Attempt a connection from the client and examine the output. Look for:
- SYN/SYN-ACK/ACK handshake (should succeed)
- RST packets with "no window, length or ip.id set" (indicates faulty hardware)
- Normal TLS/SSH handshake followed by immediate RST (indicates server issue)

If RST packets appear anomalous, the problem is likely faulty network hardware (switch, firewall). Contact network administrator to replace or reconfigure the hardware.

Advanced notes

Systemd socket-activated SSH can encounter concurrent connection issues where multiple incoming connections (e.g., IPv6 ::1 and IPv4 127.0.0.1) simultaneously cause one to be reset. If you suspect this, temporarily disable socket activation and use traditional SSH service by disabling ssh.socket and enabling ssh.service. After testing, you can re-enable socket activation if the reset was a one-time occurrence.

For OpenSSH 7.3+, newer versions provide more descriptive error messages in logs. If you're running an older version, consider upgrading to get clearer diagnostics of preauth failures.

Deprecated SSH algorithms (e.g., diffie-hellman-group1-sha1) may cause client/server incompatibility during key exchange. If both sides have these disabled, the handshake fails with a reset. Use "ssh -Q kex" to list available key exchange methods and adjust /etc/ssh/sshd_config or client ~/.ssh/config accordingly.

Frequently asked questions

What does "Connection reset by hostname port XXXXX [preauth]" mean?
The "[preauth]" tag indicates the connection was terminated before the authentication phase began. This commonly happens during the key exchange or initial protocol negotiation. The reset can originate from either the client dropping the connection unexpectedly or network hardware issues (firewalls, switches) forcing a TCP reset packet.
How do I fix "Connection reset by hostname port XXXXX [preauth]"?
The SSH server resets the TCP connection before authentication completes. This usually stems from network issues, brute-force attempts, or client timeout during key exchange.
What causes "Connection reset by hostname port XXXXX [preauth]"?
Brute-force attack attempts triggering connection limits Network hardware (switch, firewall) sending unsolicited RST packets Client timeout during key exchange negotiation
Is the "Connection reset by hostname port XXXXX [preauth]" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading