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>

tests/DodoSSH.Client.App.Tests/FakeSsh.cs

@@ -45,6 +45,31 @@ internal sealed class FakeSshConnectionFactory : ISshConnectionFactory, ISftpSes
     /// </remarks>
     internal List<SshConnectionRequest> SftpRequests { get; } = [];
 
+    /// <summary>
+    /// The furthest phase a failing attempt reports before <see cref="Failure"/> is thrown, or null for one
+    /// that never reports any.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// ◆ <b>It is what decides whether the shell goes and probes the endpoint.</b> A connection that stopped
+    /// while reaching is worth asking a socket about; one that got a host key has plainly reached the machine,
+    /// and one that never reported a phase never dialled at all. See <c>VaultViewModel.ExplainAsync</c>.
+    /// </para>
+    /// <para>
+    /// Defaults to <see cref="SshConnectionPhase.Reaching"/>, which is what this fake reported
+    /// unconditionally before the field existed, so every test written against it goes on meaning what it did.
+    /// Null models the real factory throwing out of <c>BuildConnectionInfo</c> — a private key that will not
+    /// parse — which happens before it reports anything.
+    /// </para>
+    /// </remarks>
+    internal SshConnectionPhase? FailAfter { get; set; } = SshConnectionPhase.Reaching;
+
+    /// <summary>Every phase up to and including <paramref name="furthest"/>, in the order they happen.</summary>
+    private static IEnumerable<SshConnectionPhase> PhasesUpTo(SshConnectionPhase? furthest) =>
+        furthest is { } limit
+            ? Enum.GetValues<SshConnectionPhase>().Where(phase => phase <= limit)
+            : [];
+
     /// <inheritdoc />
     public async Task<ISshConnection> ConnectAsync(
         SshConnectionRequest request,
@@ -56,7 +81,12 @@ internal sealed class FakeSshConnectionFactory : ISshConnectionFactory, ISftpSes
         // Before the gate rather than after it, which is what makes this fake useful for the connecting
         // card: a test that holds Gate open is a connection stuck partway through, and the step list has to
         // show it stuck on a named step rather than on none.
-        progress?.Report(SshConnectionPhase.Reaching);
+        //
+        // How far a failing attempt gets is FailAfter's to say; a succeeding one is always reaching by now.
+        foreach (var phase in Failure is null ? [SshConnectionPhase.Reaching] : PhasesUpTo(FailAfter))
+        {
+            progress?.Report(phase);
+        }
 
         if (Gate is { } gate)
         {
@@ -419,3 +449,42 @@ internal sealed class FakeSshShellSession : ISshShellSession
         closed.Dispose();
     }
 }
+
+/// <summary>
+/// A reachability probe that answers from a script instead of from the network.
+/// </summary>
+/// <remarks>
+/// <para>
+/// ◆ <b>Every shell in this suite is given one, and that is not only about speed.</b> The real probe resolves
+/// a name and opens a socket — see <see cref="SshReachabilityProbe"/> — so a fixture without this would put a
+/// live DNS lookup for <c>db.internal</c> and a live TCP connect in the middle of a unit suite, on every test
+/// where a connection fails. That is slow, it needs a network, and it is worse than either: <c>db.internal</c>
+/// resolves on any machine whose resolver has a search domain that makes it resolve, so the sentence the
+/// assertions read would depend on whose network the suite was run from.
+/// </para>
+/// <para>
+/// <see cref="Summary"/> defaults to empty, which is what keeps the tests that predate the probe asserting
+/// the exact message they always did: an empty finding appends nothing, so those cases go on describing a
+/// failure and nothing else. A test that is about the diagnosis sets it.
+/// </para>
+/// </remarks>
+internal sealed class FakeReachabilityProbe : ISshReachabilityProbe
+{
+    /// <summary>What every probe comes back with. Empty adds nothing to the failure it explains.</summary>
+    internal string Summary { get; set; } = string.Empty;
+
+    /// <summary>What it was asked about, in order, so a test can assert it was not asked at all.</summary>
+    internal List<string> Probed { get; } = [];
+
+    /// <inheritdoc />
+    public ValueTask<SshReachabilityReport> ProbeAsync(
+        string host,
+        int port,
+        CancellationToken cancellationToken)
+    {
+        Probed.Add($"{host}:{port}");
+
+        return ValueTask.FromResult(
+            new SshReachabilityReport(SshReach.Open, host, port, host, TimeSpan.Zero, Summary));
+    }
+}