Sync and authenticate with SSH keys on the client

Completes the client half of SSH keys: they sync alongside hosts, appear in
their own list, and can be selected to authenticate a connection instead of
typing a password.

The reconciler and the repository were Host-typed throughout, so the choice was
to generalise them or to keep a second copy per item type. Generalised, because
ItemReconciler's whole premise is that the pull and the push paths must answer
the same collision the same way — two copies would drift the first time one of
them was fixed. What is genuinely per-type now arrives through
IItemKind<TSecret>: the cipher, the merge, the plaintext columns, and the noun
to use when telling a person what happened to their item. Generic where the
server's IItemKind is not, and for the reason that reverses there — the client
needs the concrete type, because it merges field by field.

The pull filter is derived from the same registry that builds the reconcilers.
That is the specific failure being designed out: an item type that encrypts,
merges and lists perfectly and is never once requested from the server, so it
works on the machine that made it and exists nowhere else.

No client cache migration. The item table's primary key and the outbox's unique
index already carry the entity type, and AadResourceTypes already mapped SshKey
— so a host and a key may share an id and never see each other's rows, which
SshKeySyncTests now arranges deliberately.

A key hands the server nothing in plaintext. There is a public_key_fingerprint
column and it would be accepted; leaving it null is deliberate. A fingerprint is
not secret but it is a stable identifier for a key pair, so filling it would let
an operator tell which of their users hold the same key and correlate one across
vaults, for a column nothing reads. The design allows itself one plaintext
concession — the relay address, which the relay cannot work without — and this
is not that.

A key is chosen per connection rather than bound to a host, which works the way
ssh -i does. Binding one needs a field on HostSecret and therefore a payload
schema bump, which makes every host written afterwards read-only on an older
build; worth doing deliberately rather than as a side effect of adding keys.

Three things this found, all of them by being falsified rather than by review:

- Making the reconciler generic silently turned a record comparison into
  reference equality, because == on a type parameter is not value equality. The
  effect would have been a conflict recorded on every pass for an unacknowledged
  create that had in fact landed. Sabotaging the fix left all 73 tests passing —
  nothing covered that branch — so ConflictMatrixTests now has
  AnUnacknowledgedCreateThatDidLand_IsDroppedQuietly, which fails without it.

- A test asserting that a blank passphrase reaches SSH.NET as null was vacuous:
  it exercised the editor, not the credential path, and passed with the guard
  deleted. Resolved by making SshKeySecret.Passphrase normalise an empty string
  to null, so there is one spelling of one state — which also keeps two clients
  from producing different payload bytes for an identical key. That exposed a
  wider gap: SshKeySecret, its codec and its merge had no direct unit tests at
  all. They have 25 now.

- The reason first given for that normalisation was false. It claimed SSH.NET
  rejects a passphrase supplied for an unprotected key; measured against a real
  sshd it ignores it and authenticates anyway. Corrected everywhere it was
  stated and recorded in docs/platform-flags.md. The same test file also closes
  a real hole: SshPrivateKeyCredential had never been exercised against a
  server, because the existing key test builds SSH.NET's auth method directly
  and bypasses the path a vault-held key actually takes.

Only one editor may be open at a time. Both sit in the same 340-pixel column as
Auto rows and their heights together exceed it at the window's minimum size, so
two open editors put the lower one's Save and Cancel past the bottom edge — the
same failure this window already shipped once with the setup screens. Expressed
as a state rule because that is the only form of it this repository can check:
nothing here loads a .axaml. The refusal keeps what was typed, since in the key
editor that is a pasted private key the user may have nowhere else.

The end-to-end slice now carries a key as well as a host, so both item types go
through the real API, the real PostgreSQL and the real crypto in one pass — the
three hand-kept mappings between enums that do not line up are the reason that
is worth doing rather than trusting the unit suites.

735 tests green, including the container-backed SSH and end-to-end suites. Zero
warnings, dotnet format clean.
This commit is contained in:
2026-07-29 20:27:23 +02:00
parent 586cb303d5
commit e3fd3e1728
26 changed files with 2804 additions and 505 deletions
+7 -7
View File
@@ -24,7 +24,7 @@ namespace DodoSSH.Client.Domain;
/// relies on to tell "unchanged" from "changed to the same thing" from "changed differently".
/// </para>
/// </remarks>
public sealed record HostSecret
public sealed record HostSecret : IVaultSecret
{
/// <summary>The default SSH port, used when a host does not say otherwise.</summary>
public const int DefaultPort = 22;
@@ -84,33 +84,33 @@ public sealed record HostSecret
/// would make the editor unusable. The sync layer validates before sealing, and the codec
/// validates on decode, which are the two points where an invalid host would become durable.
/// </remarks>
public bool TryValidate([NotNullWhen(false)] out string? error)
public bool TryValidate([NotNullWhen(false)] out string? reason)
{
if (string.IsNullOrWhiteSpace(Label))
{
error = "A host needs a name.";
reason = "A host needs a name.";
return false;
}
if (string.IsNullOrWhiteSpace(Hostname))
{
error = "A host needs a hostname or address.";
reason = "A host needs a hostname or address.";
return false;
}
if (Port is < 1 or > 65535)
{
error = $"Port must be between 1 and 65535, not {Port}.";
reason = $"Port must be between 1 and 65535, not {Port}.";
return false;
}
if (JumpHostIds.AsSpan().Contains(Guid.Empty))
{
error = "A jump chain cannot contain an empty host id.";
reason = "A jump chain cannot contain an empty host id.";
return false;
}
error = null;
reason = null;
return true;
}
}
+31 -8
View File
@@ -29,8 +29,10 @@ namespace DodoSSH.Client.Domain;
/// <c>MemoryStream</c> rather than a file, so there is no temporary key file to leak or forget.
/// </para>
/// </remarks>
public sealed record SshKeySecret
public sealed record SshKeySecret : IVaultSecret
{
private readonly string? passphrase;
/// <summary>What the user calls this key.</summary>
public required string Label { get; init; }
@@ -48,12 +50,33 @@ public sealed record SshKeySecret
/// The passphrase protecting the private key, when it has one.
/// </summary>
/// <remarks>
/// <para>
/// Kept with the key rather than typed per connection, which is the entire point of a vault: the
/// passphrase defends the key file on a disk, and inside a vault the key is not on a disk. Storing both
/// together means the vault passphrase is what protects them, which is the guarantee this product is
/// built to make. A user who wants the second factor can leave this null and be prompted.
/// </para>
/// <para>
/// <b>An empty string is normalised to null, so there is exactly one way to say "no passphrase".</b>
/// Two spellings of one state cost more than they look: two clients that agree about a key and disagree
/// only about which spelling they used would produce different payload bytes for an identical key and a
/// spurious field conflict out of the merge, and <c>Passphrase is not null</c> would stop being a
/// reliable answer to "is this key protected?" — which is what the interface reads to describe a key.
/// Normalising here rather than at each call site means every way one can arrive lands on the same
/// value: an editor whose box was left blank, a codec decoding another client's <c>""</c>, a merge
/// picking one side.
/// </para>
/// <para>
/// It is <em>not</em> a defence against SSH.NET, which was the original reason given here and turned out
/// to be false: a passphrase handed to <c>PrivateKeyFile</c> for a key that has none is ignored, not
/// rejected, and the connection succeeds. See docs/platform-flags.md.
/// </para>
/// </remarks>
public string? Passphrase { get; init; }
public string? Passphrase
{
get => passphrase;
init => passphrase = string.IsNullOrEmpty(value) ? null : value;
}
/// <summary>
/// The public half, in <c>authorized_keys</c> form, when it is known.
@@ -78,17 +101,17 @@ public sealed record SshKeySecret
/// produces a vault item that looks fine and fails at connection time with an authentication error that
/// says nothing about which file you chose.
/// </remarks>
public bool TryValidate([NotNullWhen(false)] out string? error)
public bool TryValidate([NotNullWhen(false)] out string? reason)
{
if (string.IsNullOrWhiteSpace(Label))
{
error = "A key needs a name.";
reason = "A key needs a name.";
return false;
}
if (string.IsNullOrWhiteSpace(PrivateKeyPem))
{
error = "A key needs its private key material.";
reason = "A key needs its private key material.";
return false;
}
@@ -97,17 +120,17 @@ public sealed record SshKeySecret
if (material.StartsWith("ssh-", StringComparison.Ordinal)
|| material.StartsWith("ecdsa-", StringComparison.Ordinal))
{
error = "That is a public key. Paste the private key — the file without the .pub extension.";
reason = "That is a public key. Paste the private key — the file without the .pub extension.";
return false;
}
if (!material.StartsWith("-----BEGIN", StringComparison.Ordinal))
{
error = "That does not look like a private key; it should begin with \"-----BEGIN\".";
reason = "That does not look like a private key; it should begin with \"-----BEGIN\".";
return false;
}
error = null;
reason = null;
return true;
}
}
+37
View File
@@ -0,0 +1,37 @@
using System.Diagnostics.CodeAnalysis;
namespace DodoSSH.Client.Domain;
/// <summary>
/// What every kind of decrypted vault item has in common.
/// </summary>
/// <remarks>
/// <para>
/// Two members, and both are here because the sync layer needs them for every item type it handles: a
/// name to put in a message to a person, and the check that must pass before the item is sealed.
/// Everything else about an item — how it is encoded, how two versions of it merge, which plaintext
/// columns the server is allowed to see — is per-type behaviour that lives in the sync layer's item
/// kinds rather than on the record. The split is not arbitrary: a label and a validity rule are
/// intrinsic to the thing, whereas how it is encrypted is a decision about how it is stored.
/// </para>
/// <para>
/// An interface rather than a base record, because the implementations share no field — a base record
/// would exist solely to declare two abstract members, and would put a type in the equality contract of
/// records that have nothing else in common. The server's <c>IVaultItem</c> is an interface for a
/// sharper reason (EF Core maps a visible base class as a TPH hierarchy) but reaches the same place.
/// </para>
/// </remarks>
public interface IVaultSecret
{
/// <summary>What the user calls this item. The only name it has anywhere.</summary>
string Label { get; }
/// <summary>Whether this is storable, and why not if it is not.</summary>
/// <remarks>
/// The out parameter is <c>reason</c> rather than the <c>error</c> every implementation used before
/// this interface existed, because CA1716 refuses a reserved word from another CLR language on an
/// interface member. Renamed at the implementations too: a parameter name that differs from the one it
/// implements is legal and reads as an oversight.
/// </remarks>
bool TryValidate([NotNullWhen(false)] out string? reason);
}