How to fix Connection closed by UNKNOWN port 65535 in SSH

First, locate where you are seeing the message. This string is written by sshd on the machine being connected TO, not by the ssh client. Check the server logs:

# Debian/Ubuntu
sudo journalctl -u ssh --since "1 hour ago" | grep "Connection closed"
sudo grep "Connection closed" /var/log/auth.log

# RHEL/Fedora/Amazon Linux
sudo journalctl -u sshd --since "1 hour ago" | grep "Connection closed"
sudo grep "Connection closed" /var/log/secure

If the message is in these logs and NOT printed by an ssh command you ran, then this is inbound traffic to your server. That is the normal case and the rest of these steps apply. If instead your own ssh client prints a 'Connection closed' error, skip to the last step.

Determine whether this is many random IPs (scanner noise) or a few repeating IPs (health check / proxy). Extract and count the source addresses:

# Pull the offending lines and count by source IP (systemd)
sudo journalctl -u ssh --since "24 hours ago" \
  | grep "Connection closed by" \
  | grep -oE 'by [0-9.]+ port' \
  | awk '{print $2}' | sort | uniq -c | sort -rn | head

# From a logfile instead
sudo grep "Connection closed by" /var/log/auth.log \
  | grep -oE 'by [0-9.]+ port' | awk '{print $2}' \
  | sort | uniq -c | sort -rn | head

Interpretation:
- Many distinct IPs, low count each = internet background scanning. Harmless. Proceed to hardening.
- One or a few IPs, high regular frequency = likely a load balancer, health check, monitor, or proxy. Identify the owner before changing anything.

If the noise comes from a small set of IPs, confirm whether it is your own infrastructure probing port 22.

# Is the suspect IP inside your VPC/private range or a known LB subnet?
ip route get <suspect-ip>
whois <suspect-ip> 2>/dev/null | grep -iE 'orgname|netname|descr'

Common legitimate sources:
- AWS NLB/ELB / GCP / Azure LB: TCP health checks open the target port, then close it. Check your target group / backend health-check config — if it targets port 22 with a TCP probe, this log is expected. Consider pointing the health check at a dedicated port or an HTTP endpoint instead of 22.
- Kubernetes: a tcpSocket liveness/readiness probe on the SSH port produces this every probe interval.
- Monitoring/uptime tools doing bare TCP connects.

If you confirm it is your own health check, the log is benign — you can either accept it or move the probe off port 22 to silence it.

If the source is many random internet IPs, this is ambient scanning and is expected for any internet-facing port 22. It is not an intrusion. You can reduce log volume and exposure without disabling any security:

# See how much of your auth log is just closed connections
sudo journalctl -u ssh --since "24 hours ago" \
  | grep -c "Connection closed by"

Genuine ways to cut the noise:
- Restrict access at the network layer so scanners never reach port 22 (cloud security group / firewall allowing SSH only from known IP ranges or a VPN).
- Move SSH off port 22 to a high port — this does not add real security but dramatically reduces drive-by scanner noise.
- Leave verbose logging alone unless it is overwhelming; the lines themselves are informational.

Since the port is being probed continuously, make sure it is properly hardened. These are safe, recommended settings in /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

# Disable password auth; use keys only
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

# Disallow root login over SSH
PermitRootLogin no

# Restrict who may log in
AllowUsers deploy admin

Validate the config before reloading so you don't lock yourself out:

sudo sshd -t            # syntax check; fix any reported errors
sudo systemctl reload ssh   # or: sudo systemctl reload sshd

Keep a second session open while testing so you can revert if a key/login problem surfaces. Note: leave StrictHostKeyChecking at its default — never set it to no, and do not set MaxAuthTries 0 (that rejects all authentication, it does not make it unlimited).

fail2ban watches the SSH log and temporarily blocks IPs that repeatedly fail or abuse the port, which trims both the noise and brute-force attempts:

# Debian/Ubuntu
sudo apt-get install -y fail2ban

# RHEL/Fedora (EPEL)
sudo dnf install -y fail2ban

sudo systemctl enable --now fail2ban

Minimal jail config in /etc/fail2ban/jail.local:

[sshd]
enabled = true
port    = ssh
maxretry = 5
bantime  = 1h
findtime = 10m

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd   # see banned IPs

Bare 'Connection closed' probes that never attempt auth may not always trip the default filter, but fail2ban still handles the brute-force traffic that usually accompanies them.

If you determined in step 1 that an actual user/system you care about cannot connect (and their attempt is the source of the closed connection), debug that connection separately — this is a different problem from ambient noise. On the CLIENT machine:

ssh -vvv user@host

Look for where it stalls around kex_exchange_identification. Common real causes:
- Firewall / network path dropping the connection mid-handshake.
- MTU / MSS issues on VPNs or tunnels — try lowering MTU or enabling MSS clamping on the path.
- A corporate proxy blocking raw SSH. If the target is GitHub, SSH over HTTPS works around many proxies:

ssh -T -p 443 [email protected]

Correlate the client's source IP with the server log entry to confirm you are debugging the same connection rather than unrelated scanner noise.