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
+102 -5
View File
@@ -78,8 +78,21 @@
</Grid>
</Border>
<!-- Host list -->
<Grid Grid.Row="1" Grid.Column="0" RowDefinitions="*,Auto,Auto"
<!--
The vault column: hosts above, SSH keys below.
Two lists in one column rather than a TabControl. A TabControl is the tidier layout and it was not
chosen because of what the terminal does with the keyboard: MainWindow releases focus by calling
Focus() on HostList by name, and a tabbed version would put that target behind a tab selection. This
repository already has one measured finding of that shape — Focus() on a collapsed control is a
no-op and is not replayed when it is revealed, see the note on NativeWebView below — and whether an
unselected TabItem behaves the same way here is untested. Not worth finding out by shipping it, for
a layout preference.
The host list keeps the flexible row, so it is what grows with the window; the key section takes
what it needs and no more.
-->
<Grid Grid.Row="1" Grid.Column="0" RowDefinitions="*,Auto,Auto,Auto,Auto,Auto,Auto"
Background="#131722" IsVisible="{Binding IsUnlocked}">
<!-- Named because it is where keyboard focus lands when the user leaves the terminal. -->
@@ -138,6 +151,77 @@
<Button Content="Delete" Command="{Binding Vault.DeleteHostCommand}" />
</StackPanel>
<Border Grid.Row="3" Padding="8,6" Background="#10141d">
<TextBlock Text="SSH keys" Foreground="#9aa4b6" FontSize="11" FontWeight="SemiBold" />
</Border>
<!--
Bounded rather than flexible, and hidden while its editor is open. The key editor is the tallest
thing in this column — a private key needs a real text area — and at the window's minimum height
there is not room for both. Browsing the list and editing one of its rows are not things anyone
needs to do at the same moment.
-->
<ListBox Grid.Row="4" x:Name="KeyList" Margin="6" MaxHeight="170"
ItemsSource="{Binding Vault.Keys}"
SelectedItem="{Binding Vault.SelectedKey}"
Background="Transparent"
IsVisible="{Binding !Vault.IsEditingKey}">
<ListBox.ItemTemplate>
<DataTemplate x:DataType="vm:SshKeyRowViewModel">
<StackPanel Spacing="2" Margin="2,4">
<StackPanel Orientation="Horizontal" Spacing="6">
<TextBlock Text="{Binding Label}" Foreground="#e6e9f0" FontWeight="SemiBold" />
<Border Background="#2b2410" CornerRadius="3" Padding="4,0"
IsVisible="{Binding Badge, Converter={x:Static StringConverters.IsNotNullOrEmpty}}">
<TextBlock Text="{Binding Badge}" Foreground="#e8dcb0" FontSize="10"
VerticalAlignment="Center" />
</Border>
</StackPanel>
<!--
What is known about the key, never the key. Binding the material here would put a private
key into a list item's visual tree, where a tooltip or a screen reader could read it out.
-->
<TextBlock Text="{Binding Description}" Classes="hint" FontSize="11" />
</StackPanel>
</DataTemplate>
</ListBox.ItemTemplate>
</ListBox>
<Border Grid.Row="5" Padding="10" Background="#171b24"
IsVisible="{Binding Vault.IsEditingKey}">
<StackPanel Spacing="6">
<TextBox Text="{Binding Vault.KeyEditorLabel}" PlaceholderText="name" />
<!--
Not a password box. The armour has to be visible to be pasted and checked — a masked
multi-line box makes "did the whole key arrive?" unanswerable — and the mistake this actually
prevents is pasting the .pub file, which SshKeySecret.TryValidate rejects by name.
-->
<TextBox Text="{Binding Vault.KeyEditorPrivateKey}"
PlaceholderText="-----BEGIN OPENSSH PRIVATE KEY-----"
AcceptsReturn="True" Height="96" TextWrapping="NoWrap"
FontFamily="ui-monospace,Consolas,monospace" FontSize="11" />
<TextBox Text="{Binding Vault.KeyEditorPassphrase}"
PlaceholderText="passphrase, if the key has one" PasswordChar="•" />
<TextBox Text="{Binding Vault.KeyEditorPublicKey}"
PlaceholderText="public half (optional)" FontSize="11" />
<TextBox Text="{Binding Vault.KeyEditorNotes}" PlaceholderText="notes" AcceptsReturn="True"
Height="48" TextWrapping="Wrap" />
<TextBlock Classes="hint" FontSize="11"
Text="The key and its passphrase are encrypted here and never reach the server in a form it can read. Storing both together is the point of a vault: on a disk the passphrase protects the key, and in here your vault passphrase protects both." />
<StackPanel Orientation="Horizontal" Spacing="8">
<Button Content="Save" Command="{Binding Vault.SaveKeyCommand}" />
<Button Content="Cancel" Command="{Binding Vault.CancelKeyEditCommand}" />
</StackPanel>
</StackPanel>
</Border>
<StackPanel Grid.Row="6" Orientation="Horizontal" Spacing="6" Margin="8,4,8,8"
IsVisible="{Binding !Vault.IsEditingKey}">
<Button Content="Add key" Command="{Binding Vault.NewKeyCommand}" />
<Button Content="Edit" Command="{Binding Vault.EditSelectedKeyCommand}" />
<Button Content="Delete" Command="{Binding Vault.DeleteKeyCommand}" />
</StackPanel>
</Grid>
<!-- Terminal column -->
@@ -148,14 +232,27 @@
<!--
Typed per connection. SyncEntityType.Credential exists in the contract but is not synced
yet, so the vault genuinely does not hold this — saying so beats a password box that looks
like it should have been remembered.
like it should have been remembered. Disabled rather than hidden when a key is being used, so
it stays visible that a password is what the other choice means.
-->
<TextBox Text="{Binding Vault.ConnectPassword}" PlaceholderText="password (not stored yet)"
PasswordChar="•" Width="220" VerticalAlignment="Center" />
PasswordChar="•" Width="220" VerticalAlignment="Center"
IsEnabled="{Binding !Vault.UseKeyAuthentication}" />
<!--
An explicit switch, not "use a key if one is selected". The key list's selection is there to
edit and delete keys, and letting it decide how the next connection authenticates would mean
clicking a row to rename it changed what Connect does.
-->
<CheckBox IsChecked="{Binding Vault.UseKeyAuthentication}" Content="Use key"
VerticalAlignment="Center"
ToolTip.Tip="Authenticate with the SSH key selected in the list, instead of a password." />
<TextBlock Text="{Binding Vault.SelectedKey.Label, FallbackValue='no key selected'}"
Foreground="#bcd2ea" FontSize="11" VerticalAlignment="Center"
IsVisible="{Binding Vault.UseKeyAuthentication}" />
<Button Content="Connect" Command="{Binding Vault.ConnectCommand}"
IsEnabled="{Binding !Vault.IsBusy}" VerticalAlignment="Center" />
<TextBlock Classes="hint" FontSize="11" VerticalAlignment="Center"
Text="Credentials are not in the vault yet." />
Text="Keys are in the vault; passwords are not yet." />
</StackPanel>
</Border>