1 Commits

Include renames

Author	SHA1	Message	Date
laurensandClaude Opus 5	fd92b80d4f	Find out why a connection did not reach, instead of only saying it timed out ... Measured against SSH.NET 2026.0.0 before anything was written, because the premise needed checking. Four ways of failing to reach a host, and what this client puts in front of the user for each: server accepts TCP, never sends a banner -> "Connection has timed out." packets black-holed, nothing comes back -> "Connection has timed out." nothing listening on the port -> "...actively refused it." name does not resolve -> "No such host is known." The first two are the same five words and are not the same problem. One is a network, a firewall or a wrong address; the other is a machine that is up and well and an sshd that is wedged, or a port that is not SSH at all. Nothing in the exception tells them apart, and that sentence was the whole of what this product could say about the failure people hit most. ◆ A SOCKET ANSWERS IT, IN ABOUT AS LONG AS IT TAKES TO OPEN ONE. SshReachabilityProbe resolves the name and opens a bare TCP connection, and the four answers it can come back with are the four somebody would do something different about — unresolved, refused, silent, open. Every one of them is what a socket actually did, measured at the moment it was asked, rather than anything inferred from the exception that started it. Deliberately nothing else. No ping: ICMP is filtered on most of the networks this is pointed at, so an unanswered one would be evidence of nothing. No scan of neighbouring ports — the question is what happened to the connection the user asked for, and probing ports nobody asked about is how a client gets flagged by an intrusion detector on the very network somebody is trying to work on. No second SSH handshake against a server that has already failed one. The budget is six seconds and the floor under it is not a guess: a refusal is not immediate on Windows, and a closed loopback port took ~2s to answer when this was measured, because the stack retries the SYN first. At two seconds the probe calls a machine that is up and refusing a firewall. The test for that case runs at the real budget on purpose, so lowering the number fails it. ◆ ONLY WHILE REACHING, AND THE WINDOW IS CLOSED AT BOTH ENDS. Past SshConnectionPhase.Reaching the machine has offered a host key, so it has demonstrably been reached and a refused password is not a reachability question. Before it, nothing has been dialled at all — a private key that will not parse throws out of BuildConnectionInfo before the factory reports anything — and probing there finds a healthy port and appends "the SSH handshake is what did not finish" to a message about an unreadable key. That is a confident wrong answer replacing an accurate one, so both ends are shut. PhaseReporter keeps the furthest phase to decide it. The finding is added to what SSH.NET said rather than replacing it: the exception is the fact, and this is a reading of a second measurement. Every shell in ShellFlowTests now gets a scripted probe. Without one a failed connection in any test in that file would do a live DNS lookup for db.internal and open a real socket — slow, network-dependent, and worse than either, since db.internal resolves on any machine whose resolver has a search domain that makes it, which would make the asserted sentence depend on whose network the suite ran from. ◆ WHAT THIS DOES NOT FIX, FOUND WHILE READING THE SAME PATH. - SshConnectionRequest.ConnectTimeout is documented, plumbed, and passed by nothing. Every connection this client makes is hard-wired to the 15-second default, and there is no per-host field and no setting that can change it. Fifteen seconds bounds the handshake waits as well as the connect — a server that accepts TCP and never sends a banner fails at exactly the timeout, measured — where OpenSSH's own ConnectTimeout covers only the connect. If timeouts are frequent on slow links, this is the first suspect, and it needs a product decision rather than a patch. - The known-host lookup in HostKeyGate.OnHostKeyReceived blocks SSH.NET's message thread inside that same 15-second budget. The blocking is acknowledged in the code; that it competes with the key exchange's own timeout is not. On a cold or locked vault a slow read would surface as a connection timeout, which is exactly the symptom above. - ConnectThroughHostKeyGateAsync never unsubscribes HostKeyReceived on success, so the gate outlives the handshake holding the connect-time CancellationToken. If SSH.NET raises that event again on rekey it would re-enter the blocking store read with a token whose source is long gone. Not verified either way — it needs a real sshd and a forced rekey. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 16:05:12 +02:00