SSH Connection Reset by Peer: Trace the Failure Before Changing Config

An SSH connection that resets is different from one that is refused or simply times out. The TCP connection may have started successfully, only for the server—or something between you and it—to terminate it before you reach a password or key prompt.

That timing matters. Changing SSH keys won't fix a connection that never reached authentication. Start by finding where the connection stops, then check the server and network path.

First, identify the failure stage

You might see one of these errors:

ssh_exchange_identification: read: Connection reset by peer
kex_exchange_identification: read: Connection reset by peer
kex_exchange_identification: Connection closed by remote host

Despite the word kex, these messages often occur before the cryptographic key exchange. SSH first opens a TCP connection, then client and server exchange identification strings such as SSH-2.0-.... A reset at this point is not the same as an algorithm mismatch later in the handshake.

Run the client with verbose output:

ssh -vvv [e-mail]

Check the final lines before the error. If you never see the server's version banner, the failure is likely during the initial identification exchange. If the banner appears and the log progresses to key-exchange messages, investigate the later stage instead. The SSH verbose-mode guide explains how to read the debug output when the stopping point isn't obvious.

Next, check whether the TCP port can be reached:

nc -vz example.com 22

A successful result means a TCP connection could be established; it does not prove that SSH completed its handshake. If nc connects but ssh -vvv resets before the banner, the failure is happening after basic TCP connectivity.

On Windows, use PowerShell's built-in port test:

Test-NetConnection example.com -Port 22

Check the server before restarting anything

If you have another way to access the machine—such as a cloud console, a web shell, or an existing session—check the SSH service and its logs. The service name and log location vary by distribution:

System family	Service status	Service logs	Common auth log
Debian / Ubuntu	systemctl status ssh	journalctl -u ssh	/var/log/auth.log
RHEL / Fedora / CentOS family	systemctl status sshd	journalctl -u sshd	/var/log/secure

Look for entries at the time of the failed connection. They can help distinguish a service problem from a deliberate connection drop or a connection limit.

A few targeted checks can help:

sshd -t
sshd -T | grep -i maxstartups
ss -ltnp | grep :22

sshd -t checks configuration syntax without restarting the service. sshd -T prints effective settings, including settings that may come from included configuration files. The ss command checks whether a process is listening on port 22; adjust the port if your server uses a different one.

Avoid restarting sshd as your first move. Logs may show that the service is healthy but dropping connections for another reason. If you do need to change the server configuration, keep a working access path open while you validate and apply it. See how to check SSH server configuration safely before editing settings that could cut off your access.

Check for bans and connection limits

If the reset started after several failed login attempts, check whether a banning tool blocked your client IP. For a system using Fail2ban's SSH jail, run this on the server:

fail2ban-client status sshd

If your address is listed, that is useful evidence. But don't assume every ban appears as a reset: a firewall rule that silently drops packets usually looks like a timeout, while a rule that rejects with a TCP reset can produce a reset. The behavior depends on the configured action.

Also check for MaxStartups throttling if many unauthenticated connections are reaching the server. This setting limits simultaneous connections that have not authenticated; it is different from MaxSessions, which limits sessions within an already authenticated connection. Server logs may contain messages like:

error: beginning MaxStartups throttling
drop connection #N from [...] on [...]:22 past MaxStartups

If you find throttling, look for what is opening repeated connections—such as a reconnecting script, monitoring tool, or unwanted login attempts. Raising the limit without understanding the cause can leave the underlying problem in place. The exact client-side symptom of a dropped connection can vary, so use the server log as evidence rather than relying on the wording alone.

If the server looks healthy, isolate the network path

A firewall, VPN, corporate network, NAT gateway, or load balancer can reset traffic even when the SSH daemon is fine. Try one change at a time:

• Connect from a different network, such as mobile data. If that works, focus on the original network.
• Temporarily disconnect a VPN and test again.
• Check firewall, NAT, or load-balancer logs if the server sits behind one.
• Compare the connection time with server logs. If the server records no corresponding attempt, something may be stopping it before it reaches the host.

Some services accept SSH on port 443 as an alternative to port 22, but that only helps when the specific destination is configured to listen for SSH there. Don't assume an arbitrary server supports it.

A practical order of operations

When SSH reports a reset, work through the evidence in this order:

1. Run ssh -vvv and note whether the server banner appears.
2. Test basic TCP reachability with nc or Test-NetConnection.
3. Check the server's SSH service and logs, if you have access.
4. Look for a client IP ban or MaxStartups throttling.
5. If the server logs don't explain it, test another network and inspect devices in the path.

This keeps the troubleshooting focused on the connection stage that actually failed. A reset before authentication calls for a different investigation than a key rejection, a closed port, or a timeout.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.