sshd "Received disconnect from … port …": What the Reason Code Means

Oct 18 03:51:11 web1 sshd-session[48211]: Received disconnect from 203.0.113.7 port 54321:11: Bye Bye [preauth]
Oct 18 03:51:12 web1 sshd-session[48213]: Received disconnect from 198.51.100.22 port 40118:11: Bye Bye [preauth]
Oct 18 09:14:40 web1 sshd-session[51002]: Received disconnect from 192.0.2.44 port 51902:11: disconnected by user

What it means

An SSH client can end a connection politely by sending a disconnect packet that carries a numeric reason code and a human-readable string. sshd’s packet layer handles those packets unconditionally — the comment in the code is “Always process disconnect messages” — reads the 32-bit reason and the message out of the packet, writes this line, and returns SSH_ERR_DISCONNECTED, which ends the connection.

The format string is Received disconnect from %s port %d:%u: %.400s, so each line gives you four facts:

• The client address, taken from the connection’s remote IP.
• The client’s source port for that one TCP connection. Together with the PID in the syslog tag, this is how you tie the line to everything else that happened on the same connection.
• The reason code, printed immediately after the port with no space — port 54321:11:. It comes straight out of the packet; 11 is SSH2_DISCONNECT_BY_APPLICATION, the code a client sends when the application itself decided to close.
• The client’s message, truncated to 400 characters. It is written by the remote end, so treat it as attacker-controlled text, not as a statement of fact.

Two details are worth knowing. First, sshd logs this at INFO level only when it is the server side and the reason is SSH2_DISCONNECT_BY_APPLICATION — the code calls those “normal client exit notifications”. Any other reason code is logged at ERROR level. Second, unlike the Connection closed by … lines, this message contains no user preamble: the format uses the remote address directly, so the account the client was trying never appears here. The text after the code is whatever the client chose to send. Bye Bye is not OpenSSH’s — its client sends disconnected by user when a session ends — so a stream of Bye Bye lines points at a scripted client built on another SSH library.

Lines relayed from sshd’s pre-authentication child are tagged [preauth]; a line without that tag was written by the session process, typically when an authenticated session ends.

Is it an attack?

By itself, no — it is a client saying goodbye. What matters is what the same connection did first.

Pattern	Reading
:11: with [preauth], one per connection, many connections from one source in minutes	Scripted client opening a connection per attempt — check the preceding lines
[preauth], preceded by Failed password or Invalid user on the same PID	Brute force or name guessing ending each attempt cleanly
[preauth], with no authentication lines at all on that PID	A survey — the client negotiated, looked at the host key or banner, and left
Many different account names in the preceding lines from one source	Username enumeration
No [preauth] tag, after an Accepted line for the same PID	A normal session ending
A reason code other than 11, or odd message text	A non-OpenSSH client or library; the string is whatever its author chose
Any Accepted publickey/Accepted password from a source producing these	Stop triaging and investigate the session

Because the reason and the text are supplied by the remote end, do not build detections on the message string alone — build them on the source address and the authentication outcome, as the SSH brute-force rule does.

How to investigate

Pivot on the source address first, then on the PID of a single connection.

# 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 'Received disconnect from'

# Busiest sources (/var/log/auth.log; on RHEL/Fedora /var/log/secure)
sudo grep -oP 'Received disconnect from \K\S+' /var/log/auth.log \
  | sort | uniq -c | sort -rn | head -20

# Which reason codes and client messages you are actually seeing
sudo grep -oP 'Received disconnect from \S+ port \d+:\K\d+: [^[]*' /var/log/auth.log \
  | sort | uniq -c | sort -rn | head -20

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

# Lines with no [preauth] tag: sessions that had already authenticated
sudo grep 'Received disconnect from' /var/log/auth.log | grep -v '\[preauth\]'

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

Compare the addresses from the first count with the ones in Failed password and Invalid user lines; a source that only ever disconnects is a scanner, a source that guesses accounts first is not. For an exported auth.log, the browser log analyzer groups these lines by source.

How to stop it

You cannot stop a remote client from sending a disconnect packet, so reduce the number of connections that reach sshd and the value of each one.

• Do not expose port 22 to the whole internet. A firewall allow-list, a VPN or a bastion removes most of this volume outright.
• 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 (authfail), one that disconnects without attempting authentication for 1 second (noauth), accumulating up to a maximum of 10 minutes, with a 15-second minimum before enforcement begins. The manual warns that noauth should be used 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.
• Turn passwords off with PasswordAuthentication no (the default is yes) and, where PAM is enabled, KbdInteractiveAuthentication no — 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. PermitRootLogin defaults to prohibit-password.
• Leave LogLevel at its default of INFO. Lowering it to hide this message also hides the authentication lines you need; DEBUG levels are explicitly not recommended.

sudo sshd -t && sudo systemctl reload ssh

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