Find out why a connection did not reach, instead of only saying it timed out
ci / build and test (push) Successful in 3m3s
ci / android head (push) Successful in 4m15s
ci / api image (push) Successful in 26s
ci / desktop nightly (push) Successful in 2m15s

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>
This commit is contained in:
laurensandClaude Opus 5 committed 2026-08-26 16:05:12 +02:00
1 parent dabc691c35
commit fd92b80d4f
6 files changed
+774 -9

No files matched your search

@@ -63,6 +63,15 @@ public sealed partial class ShellFlowTests : IAsyncLifetime
/// </remarks>
private readonly FakeSshConnectionFactory ssh = new();
/// <summary>
/// The scripted answer behind every "why did that not connect" in this file.
/// </summary>
/// <remarks>
/// Silent by default — see <see cref="FakeReachabilityProbe.Summary"/> — so the cases written before the
/// diagnosis existed go on asserting the exact failure message they always did.
/// </remarks>
private readonly FakeReachabilityProbe reachability = new();
private int signInAttempts;
/// <summary>How many times a shell has tried to resume a remembered sign-in, and with what.</summary>
@@ -212,7 +221,12 @@ public sealed partial class ShellFlowTests : IAsyncLifetime
{
save = onChanged;
return new StopWatching(() => save = null);
});
},
// Scripted rather than real, so that a failed connection in any test in this file does not go
// and do a DNS lookup and open a socket. See FakeReachabilityProbe for why that matters beyond
// the wall clock.
reachability: reachability);
return ValueTask.CompletedTask;
}
@@ -2516,6 +2530,84 @@ public sealed partial class ShellFlowTests : IAsyncLifetime
tab.Steps[1].IsRunning.ShouldBeTrue("nothing moved it on after the shell let go of it");
}
/// <remarks>
/// <para>
/// ◆ <b>The reason this exists: "Connection has timed out." is what SSH.NET says for two different
/// faults.</b> A machine that never answered and a machine that answered TCP and then never spoke SSH are
/// the same five words and nothing else, and they are not the same problem. So a failure that stopped
/// while reaching now goes and looks, and what it finds is added to what was said.
/// </para>
/// <para>
/// The finding is appended rather than substituted, which is the half worth asserting: the exception is
/// the fact and the probe is a second measurement, and a test that only checked for the new sentence
/// would pass against an implementation that had thrown the original away.
/// </para>
/// </remarks>
[Fact]
public async Task AConnectionThatCouldNotReachItsHost_SaysWhatIsActuallyWrongWithIt()
{
var vault = await ReadyToConnectAsync();
await using var renderer = await FakeRenderer.AttachAsync(workspace, Token);
ssh.Failure = new InvalidOperationException("Connection has timed out.");
reachability.Summary = "Port 22 on db.internal accepts connections.";
await vault.ConnectCommand.ExecuteAsync(null);
var tab = shell.Tabs.ShouldHaveSingleItem();
tab.Status.ShouldBe("Connection has timed out. Port 22 on db.internal accepts connections.");
reachability.Probed.ShouldHaveSingleItem().ShouldBe("db.internal:22");
}
/// <remarks>
/// Past <see cref="SshConnectionPhase.Reaching"/> the machine has offered a host key, so it is plainly
/// reachable and there is nothing a socket could add. A refused password that came back with "the network
/// is fine and something is listening" bolted on would be true, useless, and read as though the client
/// had not understood the question.
/// </remarks>
[Fact]
public async Task AConnectionRefusedAfterTheHostKey_IsNotProbed()
{
var vault = await ReadyToConnectAsync();
await using var renderer = await FakeRenderer.AttachAsync(workspace, Token);
ssh.FailAfter = SshConnectionPhase.Authenticating;
ssh.Failure = new InvalidOperationException("Permission denied (publickey,password).");
reachability.Summary = "this must not be appended";
await vault.ConnectCommand.ExecuteAsync(null);
shell.Tabs.ShouldHaveSingleItem().Status.ShouldBe("Permission denied (publickey,password).");
reachability.Probed.ShouldBeEmpty("the host key proved the machine was reached");
}
/// <remarks>
/// ◆ <b>The other end of the window, and the one that would state something false.</b> A failure with no
/// phase reported at all never dialled — the real factory throws out of <c>BuildConnectionInfo</c> on a
/// private key it cannot parse, before the socket is opened. Probing there finds a perfectly healthy port
/// and appends "the SSH handshake is what did not finish" to a message about an unreadable key, which is
/// a confident wrong answer replacing an accurate one.
/// </remarks>
[Fact]
public async Task AFailureBeforeAnythingWasDialled_IsNotProbed()
{
var vault = await ReadyToConnectAsync();
await using var renderer = await FakeRenderer.AttachAsync(workspace, Token);
ssh.FailAfter = null;
ssh.Failure = new InvalidOperationException("The private key could not be read.");
reachability.Summary = "this must not be appended";
await vault.ConnectCommand.ExecuteAsync(null);
shell.Tabs.ShouldHaveSingleItem().Status.ShouldBe("The private key could not be read.");
reachability.Probed.ShouldBeEmpty("nothing had been dialled, so there was nothing to ask about");
}
/// <remarks>
/// A refusal has to end up somewhere the user will see it, and by the time one arrives they are quite
/// likely looking at another screen — which is exactly what not blocking bought. The tab is that place,