sshd "error: kex_exchange_identification": What It Means

Oct 18 03:51:11 web1 sshd-session[48211]: error: kex_exchange_identification: read: Connection reset by peer
Oct 18 03:51:12 web1 sshd-session[48213]: error: kex_exchange_identification: read: Connection reset by peer
Oct 18 04:19:47 web1 sshd-session[49004]: error: kex_exchange_identification: read: Connection reset by peer

What it means

The prefix before the colon is a function name. kex_exchange_identification() lives in sshd’s kex.c and, as the comment above it puts it, “Sends our identification string and waits for the peer’s. Will block for up to timeout_ms (or indefinitely if timeout_ms <= 0).” That exchange of version banners (SSH-2.0-...) is the very first thing that happens on a new connection — before key exchange, before any user name is offered, before PAM is involved at all.

sshd reads the peer’s banner one byte at a time, and the code has three ways out that produce a message:

• The read fails. If the one-byte read does not return a byte and errno is not EPIPE, sshd logs read: %.100s with the system error text — giving lines such as error: kex_exchange_identification: read: Connection reset by peer. This is logged at error level, so it is visible at the default LogLevel of INFO.
• The peer closed the connection (errno == EPIPE). sshd logs Connection closed by remote host through its verbose logging call, so a server left at the default INFO level never records it.
• The banner is malformed. A NUL byte, or any byte arriving after a carriage return that is not a newline, produces banner line contains invalid characters — again at verbose level — and the connection is treated as invalid.

Note what the line does not contain: no address, no port, no user. Those are in the companion line that the same process writes when it gives up — usually an untagged Connection closed by <ip> port <n> or Connection reset by <ip> port <n>, untagged because the pre-authentication child does not exist yet. See the Connection closed / reset page for how to read it.

Is it an attack?

Almost always it is not an attack in itself; it is the trace of a connection that never became an SSH session.

Pattern	Reading
Isolated lines, scattered through the day	Internet-wide port surveys and banner grabs hanging up after the TCP handshake
Steady, regular cadence from a host you own	A monitoring system doing TCP-only checks against port 22
Short bursts, several per second	A scanner working through your address range, or a client retrying hard
Lines with no following Connection closed/reset entry	Check whether the log is being rate-limited or rotated mid-burst
These lines, then Failed password or Invalid user from one address	The scan found the service and a brute-force tool came back — treat as a brute-force investigation

Middleboxes also generate them: a firewall, IPS or NAT device that resets idle or disallowed flows produces read: Connection reset by peer on the server side even though the human client did nothing wrong. Clients that speak the wrong protocol to port 22 (an HTTP or TLS probe, for example) fall into the malformed-banner branch, which stays invisible at INFO.

How to investigate

The line has no address, so investigation means pivoting on the process ID and on the lines written around it.

# Debian/Ubuntu unit is ssh; on RHEL/Fedora use -u sshd
sudo journalctl -u ssh --since "24 hours ago" | grep 'kex_exchange_identification'

# Rate over the day: a steady background or a burst? (traditional auth.log timestamps)
sudo grep 'kex_exchange_identification' /var/log/auth.log \
  | awk '{print $1, $2, substr($3,1,2)}' | uniq -c

# No address in the line — follow the PID to the rest of that connection
sudo grep 'sshd-session\[48211\]' /var/log/auth.log

# Connections that ended before the preauth child existed carry the addresses
sudo grep -E 'Connection (closed|reset) by' /var/log/auth.log | grep -v '\[preauth\]' \
  | awk '{print $(NF-2)}' | sort | uniq -c | sort -rn | head -20

# The question that changes severity: did anything from those sources get in?
sudo grep -E 'Accepted (publickey|password)' /var/log/auth.log | tail -50

On a host where rsyslog is not installed, read the journal instead of /var/log/auth.log; on RHEL and Fedora the file is /var/log/secure. For an exported auth.log, the browser log analyzer groups the surrounding connection lines by source, and the SSH brute-force rule covers the follow-on stage where one source starts naming accounts.

How to stop it

You cannot stop a remote peer from hanging up mid-banner, so aim at volume and exposure.

• Reduce who can reach port 22. A firewall allow-list, a VPN or a bastion removes the scan traffic that produces most of these lines. Nothing else cuts the rate as much.
• Understand that key-only authentication does not help here. This failure happens before authentication, so turning off PasswordAuthentication (default yes) changes nothing about these lines — it changes what happens to the sources that get further.
• Leave PerSourcePenalties enabled. The manual says penalties are on by default; noauth refuses clients that “disconnect without attempting authentication” for 1s by default, accumulating up to max (default 10m), with min (default 15s) of penalty accrued before enforcement begins. The manual warns that this timeout “should be used cautiously otherwise it may penalise legitimate scanning tools such as ssh-keyscan(1)”.
• Keep the unauthenticated-connection limits in place. LoginGraceTime (“The server disconnects after this time if the user has not successfully logged in”, default 120 seconds) and MaxStartups (maximum concurrent unauthenticated connections, default 10:30:100) bound how much a flood of half-finished connections can cost you.
• Fix your own noise. If a monitoring system opens and closes TCP connections to port 22, point it at a check that completes a handshake, or document the source so triage skips it.
• Raise LogLevel to VERBOSE only when you need the other two variants, and not to DEBUG: the manual states that “Logging with a DEBUG level violates the privacy of users and is not recommended.”

sudo sshd -t && sudo systemctl reload ssh

Test the configuration before reloading, and keep a working session open until a new one succeeds.