SSH Connection Closed by UNKNOWN Port 65535

SSH Connection closed by UNKNOWN port 65535 usually means an indirect SSH channel closed before the client established a normal connection to the final destination. Port 65535 is commonly a placeholder in the message, not a port you should open.

Why the message is misleading

A failure can end with these lines:

kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535

The final line lacks the normal peer address and port because the current SSH process is communicating through an indirect channel, such as a ProxyCommand or the standard-input and standard-output forwarding created by ProxyJump. When that channel closes, the client may not have a conventional peer socket to report. The placeholder does not mean the destination SSH daemon moved to TCP port 65535.

The useful evidence is usually several lines earlier, where the jump command, forwarding channel, DNS lookup, or destination connection first failed.

See the configuration SSH actually evaluated

SSH configuration can combine system files, user files, Included files, Host patterns, Match conditions, command-line options, and application wrappers. Print the final values for the destination:

ssh -G destination.example
ssh -vvv destination.example

In ssh -G output, inspect hostname, port, user, proxyjump, proxycommand, canonicalizehostname, identityfile, and control-socket settings. In verbose output, look for a line showing the proxy command or jump-host connection that SSH executed.

How ProxyJump creates another SSH hop

ProxyJump connects to a bastion and asks it to forward a byte stream to the destination host and port. Conceptually, a command resembles this:

ssh -W destination.internal:22 bastion.example.net

The outer SSH client then performs the destination SSH handshake over that stream. A failure can therefore occur in at least two places: the client-to-bastion SSH connection, or the bastion-to-destination TCP connection. Debug each hop separately.

Step 1: connect to the jump host directly

ssh -vvv bastion.example.net

Resolve host-key, key-selection, agent, and authentication problems on the jump host before testing the destination. If the bastion connection itself is unreliable, the final destination error cannot be trusted as the primary symptom.

Step 2: test destination resolution from the jump host

An internal destination name may resolve on the bastion but not on the client, or the reverse. ProxyJump normally asks the jump side to connect to the destination passed through the forwarding channel. Log in to the bastion and test the same destination name in that environment:

getent hosts destination.internal
nslookup destination.internal

If SSH configuration replaces the hostname, test the evaluated value from ssh -G, not merely the alias typed on the command line.

Step 3: test the destination port from the jump host

nc -vz destination.internal 22
ssh -vvv destination.internal

The first command tests TCP reachability when netcat is available. The second performs the complete SSH negotiation from the bastion. A timeout points toward routing, firewall, security-group, VPN, or host availability. A refusal means the address responded but nothing accepted that port, or a firewall rejected it. An immediate banner or key-exchange close points toward sshd policy, connection limits, access controls, or a middlebox.

Common underlying causes

The destination is unreachable from the bastion

The client may reach the bastion successfully while the bastion lacks a route, firewall rule, security-group permission, or name resolution for the target. Test from the bastion network rather than from the original client. Record which address the bastion resolved, because split DNS can send the two hosts toward entirely different destination interfaces.

ProxyCommand exits early

Custom ProxyCommand scripts can fail because a helper executable is missing, arguments are quoted incorrectly, a local proxy is unavailable, or the helper writes an error and closes its stream. Run the command shown in verbose output independently, after removing sensitive values, and inspect its own exit status and error text.

A stale multiplexed connection is being reused

ControlMaster can reuse an existing SSH transport. A stale control socket or broken master connection may produce confusing downstream errors. Check the evaluated controlmaster and controlpath settings, close the named master deliberately, and retry without multiplexing as a diagnostic comparison.

ssh -O check bastion.example.net
ssh -O exit bastion.example.net
ssh -o ControlMaster=no -vvv -J bastion.example.net destination.internal

The SSH service closes during identification or key exchange

Connection limits, automated blocking, tcpwrappers on older systems, fail2ban-like controls, overloaded sshd processes, malformed traffic, or access policy can close a connection before authentication. Check server logs at the matching timestamp. Client output alone cannot reveal a server-side reason that was never sent over the protocol.

An application adds its own SSH layer

Editors, deployment tools, Git clients, and file-transfer applications may generate temporary SSH configuration or wrap the client. Reproduce the evaluated command in a normal terminal and compare its configuration. The wrapper's final error can omit the earlier line that identifies which hop failed.

What not to do

Do not open port 65535 in a firewall merely because it appears in this message.
Do not replace SSH keys when the failure occurs before destination authentication.
Do not disable host-key checking to work around a forwarding or transport close.
Do not test only from the client when the failing connection originates from a bastion.

A reliable diagnostic sequence

Run ssh -G for the final destination and record the proxy, hostname, port, and user.
Run the final connection with -vvv and find the first failure before the port 65535 line.
Connect to each jump host directly.
From the relevant jump host, test destination DNS and TCP port reachability.
Check jump-host and destination SSH logs at the same timestamp.
Test without connection multiplexing and without application wrappers.
Correct the failed hop, then retest the complete chain.

Authoritative references

The OpenSSH ssh_config manual documents ProxyJump, ProxyCommand, configuration evaluation, token expansion, and multiplexing controls. The OpenSSH client manual documents the three verbose levels used to trace configuration, connection, authentication, and session setup.