kex_exchange_identification Reset by Peer: sshd Penalties

Shortly after noon KST today, my spare sshd started refusing a key it had accepted minutes earlier. The client printed kex_exchange_identification: read: Connection reset by peer and exited 255. Nothing was wrong with the key, the network or the server process. Four wrong-key attempts had come from the same address in the previous second, and OpenSSH was blocking 127.0.0.1 for about 20 seconds. I hit that while writing the known_hosts vs authorized_keys probes and gave it one paragraph there. This post goes further. I ran 18 fresh throwaway sshd processes to find what triggers the block, how long it lasts and what the client prints while it's on.

The block comes from PerSourcePenalties, which OpenSSH 9.8 turned on by default on July 1, 2024. I then pulled every Stack Exchange question with kex_exchange_identification in the title. There are 72 of them across five sites, with 2,337,891 views between them and 117 answers. None of the answers mentions penalties.

What the error means

An SSH connection opens with both sides sending a version line, something like SSH-2.0-OpenSSH_10.2. kex_exchange_identification is the client function that reads the server's line. If the TCP connection dies before a valid line arrives, you get one of these:

kex_exchange_identification: read: Connection reset by peer
Connection reset by 127.0.0.1 port 2223

kex_exchange_identification: Connection closed by remote host
Connection closed by 127.0.0.1 port 2223

So the error only says the server side hung up before the handshake. The top Stack Overflow question (663,540 views) has an accepted answer that says the same: either the sshd process is failing or something between you and it is cutting the connection. That's still true. Since 9.8 there's a third option: sshd accepts the connection on purpose and drops it because of where it came from.

What sshd sends when it blocks you

The drop happens in drop_connection() in sshd.c. Before closing the socket, the listener writes one line: Not allowed at this time. nc shows it verbatim. ssh -v shows it as debug1: kex_exchange_identification: banner line 0: Not allowed at this time, which explains why "kex_exchange_identification not allowed at this time" shows up in Google's autocomplete.

Without -v you never see that line, and the visible message isn't even consistent. I made 20 attempts against one active block at the default log level. Eleven printed only Connection closed by 127.0.0.1 port 2223. Nine printed read: Connection reset by peer. With -v it split 6 to 9, and with -vvv 9 to 6. My guess is a race between the server's close and the client's own version line reaching the socket, but I didn't prove that. The practical point is that the two most-viewed titles in this error family can have one cause. "Connection closed by remote host" on Server Fault has 927,392 views. If your scripts run with LogLevel=ERROR, the first blocked attempts printed nothing at all, just exit 255.

What triggers a block, measured

The lab was macOS 26.4.1 with OpenSSH_10.2p1 on both ends. It ran a non-root /usr/sbin/sshd -D -e on 127.0.0.1:2223 with throwaway keys and a fresh process for every experiment, because the penalty table lives in the listener. sshd -T printed these defaults:

persourcepenalties crash:90 authfail:5 noauth:1 grace-exceeded:10
  refuseconnection:10 max:600 min:15 ...
persourcenetblocksize 32:128
maxstartups 10:30:100

Each bad event adds its number of seconds to the source address. Nothing is enforced until the total passes min (15 seconds), and it drains in real time. The sshd_config manual describes the rules. These are the results:

Three things in there surprised me.

Sequential failures stop counting once the block starts. Four failures and ten failures both gave about 20 seconds. After the block activates, the extra attempts are dropped before they can authenticate, so they add nothing. Retrying once a second during the block didn't extend it either.

Parallel failures stack, and the log undersells it. Twelve wrong-key connections fired at once logged activating ipv4 penalty of 20 seconds. The connections still in flight then kept adding time until the log read 50 seconds remaining. The right key got in after 55.7 seconds. The max is 600 seconds, so in principle a burst of parallel jobs sharing one bad key could lock a CI runner out for up to ten minutes. I didn't push it that far.

Connections that never try to log in count too. A bare TCP connect and close costs 1 second (noauth). Back to back, the 18th check got Not allowed at this time. ssh-keyscan opens several connections per run, and my third run tripped it. The rate is what matters: one check per second never triggered in 40 tries because each 1-second penalty had drained before the next arrived. At roughly two per second, the 43rd check was blocked. A monitor probing every 10 seconds, like the HAProxy health check on Server Fault, won't trip it on its own.

That HAProxy question points at the real risk, though. A proxy, a bastion or a NAT gateway makes every user behind it the same source address. One user fumbling a key four times blocks everyone behind the proxy for 20 seconds. The 9.8 release notes warn about exactly this: servers "that accept connections from addresses behind NAT or proxies may need to consider these settings."

Penalty or MaxStartups? Read the server log

Here's the trap I nearly fell into with the exemption test. I exempted 127.0.0.1 and fired 12 parallel failures, and one connection was still dropped. That drop was MaxStartups, the older limit on unauthenticated connections in flight, which starts refusing at random past 10. It goes through the same function and sends the client the same banner. Only the server log tells them apart:

drop connection #0 from [127.0.0.1]:58347 on [127.0.0.1]:2223 penalty: failed authentication
drop connection #11 from [127.0.0.1]:58108 on [127.0.0.1]:2223 Maxstartups

That log undercounts, though. In one run at least 20 connections were refused and seven drop connection lines were written, because sshd rate-limits them (a change noted in the 10.0 release). Before 10.1, enforcement was logged at VERBOSE, so a default config showed nothing. On Linux, journalctl -u ssh (or -u sshd) piped to -E "drop connection|srclimit_penalise" is the first thing to run. Autocomplete suggests people already search these lines, for example "sshd penalty connections without attempting authentication" and "ssh penalty exceeded logingracetime".

The fix, by case

• You're the one blocked: stop retrying, wait 20 seconds, and fix the key or user first. For parallel jobs, find the key problem with a single connection before fanning out.
• Trusted monitoring or bastion addresses: exempt them. With PerSourcePenaltyExemptList 127.0.0.1, 12 parallel failures left the right key working.
• Health checks: probe no faster than once a second per source, or use a check that completes an SSH login.
• Behind NAT, as a last resort: PerSourcePenalties no turned it off completely in my lab. That also removes the brute-force protection it exists for. My own Tailscale SSH setup keeps the default.

One version note: the current OpenBSD manual lists an invaliduser penalty, but 10.2p1's sshd -T doesn't have it. The 10.3 release notes (April 2, 2026) add it, along with sub-second penalties. Check sshd -T on your own build before copying a config.

The 72 questions

I pulled the questions through the Stack Exchange API's title search on Stack Overflow, Server Fault, Super User, Unix & Linux and Ask Ubuntu. They split 34, 12, 10, 9 and 7, dated 2019 to 2025. Forty-five have answers and 18 have an accepted one. Matching keywords across the 117 answers, the causes offered were VPNs, proxies or the network (15 questions), firewalls (11), restarting or reconfiguring sshd (8), host keys or permissions (7), GitHub over port 443 (6), Docker or WSL (4), hosts.allow/deny (3), MaxStartups (2) and fail2ban (2). The count for "penalt" in answers or question bodies was 0. Only four of the 72 were asked after 9.8 shipped, so I can't say how many askers actually hit a penalty. What I can say is that if you did hit one, none of these threads would lead you to it. On a headless machine like this one, where a lockout means a trip to the hardware, I'd rather know which kind of "reset by peer" I'm looking at.

FAQ

What does kex_exchange_identification: read: Connection reset by peer mean?

The server side closed the TCP connection before sending its SSH version line. On OpenSSH 9.8 or later, one cause is PerSourcePenalties blocking your address after failed logins or rapid connections. Others are a crashed sshd, a firewall, a proxy or MaxStartups. The server log line "drop connection ... penalty:" confirms a penalty.

How long does an sshd penalty block last?

With OpenSSH 10.2p1 defaults, four failed logins in a row blocked my address for about 20 seconds, and further sequential attempts didn't extend it. Twelve failures at the same moment blocked it for 55.7 seconds. The configured maximum is 10 minutes.

How do I stop sshd from blocking my monitoring or bastion host?

Add its address or CIDR range to PerSourcePenaltyExemptList in sshd_config and reload sshd. In my test, an exempted address kept logging in after 12 failures. Setting PerSourcePenalties no also works but disables the protection for everyone.

Sources and method: the experiments ran on September 18, 2026 between 13:34 and 13:58 KST on macOS 26.4.1 with OpenSSH_10.2p1 client and server. The server was a non-root sshd on 127.0.0.1:2223 at LogLevel DEBUG1, with throwaway host and client keys, -F /dev/null on the client and a new sshd process for each experiment. The system sshd and my real ~/.ssh were not touched. Linux builds, IPv6, PerSourceNetBlockSize grouping (I only had one source address), the crash penalty and the overflow modes weren't tested. Option behavior is quoted from the OpenBSD sshd_config manual, the 9.8, 10.0, 10.1 and 10.3 release notes, and sshd.c in openssh-portable. The Stack Exchange numbers come from the API's title search on five sites, fetched September 18. The cause buckets use keyword matching and undercount. There are no affiliate links in this post.