sshd "Connection closed by …" / "Connection reset by …": What It Means

Oct 18 03:51:11 web1 sshd-session[48211]: Connection closed by 203.0.113.7 port 54321 [preauth]
Oct 18 03:51:44 web1 sshd-session[48230]: Connection closed by invalid user admin 198.51.100.22 port 40118 [preauth]
Oct 18 03:52:40 web1 sshd-session[48244]: Connection closed by authenticating user deploy 198.51.100.22 port 40162 [preauth]
Oct 18 04:07:02 web1 sshd-session[48502]: Connection reset by 192.0.2.44 port 51902 [preauth]

What it means

Both lines come from the same place in sshd: the handler that, in its own words, exists to “pretty-print connection-terminating errors and exit”. When the packet layer reports that the connection was closed, sshd logs Connection closed by %s; when a system call fails with errno == ECONNRESET, it logs Connection reset by %s. In both cases the remote end stopped talking and sshd gave up on that connection.

The %s is a connection identifier built from three parts — an optional logging preamble, the client’s IP address and the client’s source port, formatted as %.200s%s%s port %d. That gives you the three facts worth reading:

• The address and port. The port is the client’s source port for that single TCP connection, which is how you tie this line to the other lines sharing the same PID.
• The user preamble, when present. sshd installs it while processing the first authentication request, using "authenticating " when the account lookup produced a usable record and "invalid " when it did not. So authenticating user deploy means the name matched an account sshd was willing to try, and invalid user admin means it did not — the same distinction described on the Invalid user page and in Failed password lines. No preamble at all means the client never asked to authenticate as anybody.
• The [preauth] tag. sshd’s monitor appends [preauth] to messages relayed from the pre-authentication process. Without it, the line came from the session process itself: either before that child exists — sshd-session runs the banner exchange first, so a client that connects and hangs up before key exchange is logged untagged — or after login, from the session’s main loop.

Is it an attack?

Usually it is noise, but the variants read very differently.

Pattern	Reading
No user name, [preauth], one connection per source	Banner grab or port survey — ssh-keyscan-style probes and internet-wide scanners
No user name, [preauth], many connections from one source in seconds	Scripted scanning or a client retrying after a failed key exchange
invalid user <name>, many different names from one source	Name guessing — correlate with the Invalid user and Failed password lines on the same PIDs
authenticating user <real account> after password failures	A brute-force client giving up on an account that actually exists — higher priority
No user name and no [preauth], often after a kex_exchange_identification error	The client left during the banner exchange, before key exchange — port checkers and scanners
No [preauth], from an address with an Accepted line earlier	An established session dropped — network path, NAT timeout or a killed client
Any of the above followed by Accepted from the same address	Stop triaging and investigate the session

The line itself never means anyone authenticated. It is the ending of a story told by the lines before it, so always read the connection as a whole.

How to investigate

Pivot on the source address and on the PID that each connection used.

# Last 24 hours from the journal (Debian/Ubuntu unit is ssh; RHEL/Fedora use -u sshd)
sudo journalctl -u ssh --since "24 hours ago" | grep -E "Connection (closed|reset) by"

# Busiest sources (/var/log/auth.log; on RHEL/Fedora /var/log/secure)
sudo grep -oP 'Connection (?:closed|reset) by (?:(?:authenticating|invalid) user \S+ )?\K\S+' \
  /var/log/auth.log | sort | uniq -c | sort -rn | head -20

# Which account names clients were working on when they hung up
sudo grep -oP 'Connection (?:closed|reset) by (?:authenticating|invalid) user \K\S+' \
  /var/log/auth.log | sort | uniq -c | sort -rn | head -20

# Lines without [preauth]: the client left during the banner exchange, or a logged-in
# session dropped — check for an earlier Accepted line from the same address
sudo grep -E "Connection (closed|reset) by" /var/log/auth.log | grep -v '\[preauth\]'

# The full story of one connection, by PID
sudo grep 'sshd-session\[48230\]' /var/log/auth.log

# Did anything from these sources actually get in?
sudo grep -E "Accepted (password|publickey)" /var/log/auth.log | tail -50

Names from the second-to-last command should be checked against /etc/passwd: an authenticating user preamble for a real service or staff account deserves more attention than a thousand invalid user closes. For an exported auth.log, the browser log analyzer groups these lines by source, and the SSH brute-force rule encodes the one-source-many-names pattern as a detection.

How to stop it

You cannot stop a remote client from hanging up, so the goal is fewer unwanted connections and less value in each one.

• Do not expose port 22 to the whole internet. Restrict it at the firewall, or put it behind a VPN or bastion. Nothing else cuts the volume as much.
• Leave PerSourcePenalties enabled. The manual says penalties are on by default; a client that disconnects after one or more unsuccessful authentication attempts is refused for 5 seconds by default, accumulating up to a maximum of 10 minutes, with a minimum of 15 seconds of accrued penalty before enforcement begins. The noauth penalty (default 1s) covers clients that disconnect without attempting authentication — the manual warns to use it cautiously, as it may penalise legitimate scanning tools such as ssh-keyscan(1).
• Keep LoginGraceTime (default 120 seconds) and MaxAuthTries (default 6) tight, so a connection that lingers or guesses is cut off sooner.
• Remove passwords from the equation with PasswordAuthentication no (it defaults to yes), and, where PAM is enabled, KbdInteractiveAuthentication no as well — the manual notes PAM keyboard-interactive authentication usually serves an equivalent role to password authentication.
• Limit who may log in with AllowUsers; by default login is allowed for all users, and patterns may take the USER@HOST form with CIDR host criteria.

sudo sshd -t && sudo systemctl reload ssh

Validate the configuration before reloading, and keep an existing session open until a new one works.