Connection closed by UNKNOWN port 65535 looks alarming and means something mundane: the SSH connection died before it got far enough to know who it was talking to. UNKNOWN is SSH admitting it never learned the remote host’s identity, and 65535 is a placeholder port, not a real one - together they just mean the session collapsed during the earliest handshake. The real cause is one of a short list: too many authentication attempts, a key-exchange or cipher mismatch, a proxy or firewall cutting the connection, or the server dropping you before auth. Read the placeholder as blank, run ssh -v, and the actual reason is one line up.
The error text is a red herring. Nobody is on port 65535, and UNKNOWN is not a hostname. Stop trying to decode the numbers and read what happened just before them.
Table of contents
- What UNKNOWN and 65535 actually mean
- Cause 1: too many authentication failures
- Cause 2: key exchange or cipher mismatch
- Cause 3: a proxy or firewall in the middle
- The order to diagnose it in
- How this fits the rest of the stack
- FAQ
What UNKNOWN and 65535 actually mean
SSH prints this message when the connection is torn down before the identity of the peer is established. Two placeholders explain the scary text:
- UNKNOWN - SSH never resolved the remote hostname for this session, so it substitutes
UNKNOWN. It is not a server called UNKNOWN; it is a blank. - port 65535 - a sentinel value (the maximum possible port number) used when the real port was never negotiated. It is a stand-in for “no port”, not an actual port anyone is listening on.
So the message reduces to: the connection ended before the SSH session was set up. That happens in the first few round-trips of the protocol - the banner exchange, key exchange, or authentication. Which of those failed is what you need to find, and the numbers in the error will not tell you. ssh -v will.
Cause 1: too many authentication failures
The most common trigger is the client offering more keys than the server allows before giving up.
If your SSH agent has several keys loaded, the client tries each one in turn. The server has a MaxAuthTries limit (often 6), and once the client burns through it with wrong keys, the server drops the connection - reported as this error. The tell in ssh -v is a run of Offering public key: lines followed by the disconnect.
The fix is to tell SSH exactly which key to use, and to stop it offering the others:
ssh -i ~/.ssh/the_right_key -o IdentitiesOnly=yes user@hostIdentitiesOnly=yes stops the agent from throwing every key at the server. If that connects, make it permanent with an entry in ~/.ssh/config for that host.
Cause 2: key exchange or cipher mismatch
If the client and server share no common algorithm for key exchange, ciphers, or MACs, the handshake fails before authentication - and you get this error.
It shows up when a modern client talks to a very old server (or the reverse), because newer OpenSSH has retired weak algorithms that an ancient server only offers. ssh -v shows the negotiation failing around the kex or cipher lines.
The fix is to explicitly allow the older algorithm - but only as a deliberate, temporary measure against a box you cannot upgrade:
ssh -o KexAlgorithms=+diffie-hellman-group14-sha1 user@hostThe real fix is to update the out-of-date end. Re-enabling deprecated crypto is a workaround for reaching a legacy machine, not a setting to leave in your config for everything.
Cause 3: a proxy or firewall in the middle
In a corporate network, the connection often has to go through an HTTP proxy, and if the proxy is misconfigured or blocking SSH, it kills the session mid-handshake - reported the same way.
Signs you are in this case: it works from home but not on the office network, or works to one host but not another. People tunnel SSH through the proxy with a tool like corkscrew and a ProxyCommand in ~/.ssh/config. If that tunnel itself is broken, you get Connection closed by UNKNOWN port 65535 because the proxy dropped you before SSH ever reached the server.
Test the proxy path directly before blaming SSH. If a plain connection to the proxy hangs or fails, the problem is the proxy, not your keys or the server - and no amount of key fiddling will fix a proxy that is not forwarding.
The order to diagnose it in
Work from cheapest to most involved:
- Run
ssh -vvv user@host. The last few lines before the disconnect name the phase that failed - auth, kex, or banner. This alone usually solves it. - If it is auth: add
-o IdentitiesOnly=yes -i <key>to rule out the too-many-keys case. - If it is kex/cipher: note the algorithms offered; you are talking to something too old or too new, and the fix is to upgrade the other end.
- If it is neither and you are on a managed network: suspect the proxy or firewall. Test the network path independently.
Almost every instance of this error is case 1. Start there, let the verbose log point you, and ignore the literal 65535 entirely - it never had anything to tell you.
How this fits the rest of the stack
Whatever you decide here, the cost of it eventually shows up as a bill. The RunxBuild hosting calculator is the right place to model that before committing: the compute, the database, the storage, the bandwidth, the worker - each one is a separate line item, and the real cost of a platform is the sum, not the headline number. The RunxBuild dashboard is where the team sees the actual usage once it is running.
Useful related references:
- Connection Refused on SSH Port 22: Refused Is Not Timed Out
- 443 Port TCP: HTTPS, TLS Handshake, and Firewall Rules
- SSH Connection Refused: 7 Causes and the Right Fix
- Database connection limits on RunxBuild
FAQ
What does connection closed by UNKNOWN port 65535 mean?
It means the SSH connection died before the session was established - during the banner, key exchange, or authentication phase. UNKNOWN is a placeholder for the unresolved remote host and 65535 is a sentinel for a port that was never negotiated. Neither is a real address; the error just means the handshake collapsed early.
How do I fix connection closed by UNKNOWN port 65535?
Run ssh -vvv to see which phase failed. The most common cause is too many keys being offered - fix it with ssh -i <key> -o IdentitiesOnly=yes user@host. Other causes are a key-exchange or cipher mismatch with an old server, or a proxy/firewall cutting the connection on a managed network.
Why does SSH say port 65535 when I connected to port 22?
65535 is not the port you connected to - it is a sentinel value (the maximum port number) that SSH uses when the real port was never negotiated because the session failed early. It is the protocol’s way of saying no port, not a claim that the server is listening on 65535.
What is IdentitiesOnly in SSH?
IdentitiesOnly=yes tells SSH to use only the key you specify with -i and stop the agent from offering every loaded key. This prevents the client from exhausting the server’s MaxAuthTries limit, which is the most frequent cause of the connection-closed error when you have several keys loaded.
Can a proxy cause the connection closed by UNKNOWN error?
Yes. On corporate networks SSH often routes through an HTTP proxy, and if the proxy blocks or mishandles SSH it drops the connection mid-handshake, producing this error. A tell is that it fails only on that network. Test the proxy path directly - if it hangs, the problem is the proxy, not your keys.