Gebauter Stand mit Worker: fremder Key auf dem Testziel, Abgleich
zeigt ihn als unbekannt, Uebernahme in den Block mit Dry-Run, danach
keine offenen Abweichungen. Der Test raeumt einen Benutzer deploy aus
frueheren Laeufen weg - genau den hat der Abgleich zu Recht als von
Hand geaenderten Block gemeldet.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Bisher liess sich nur je Schluessel oder je Host nachsehen, wo ein Key
verwaltet ist. Die Matrix zeigt das auf einen Blick, loest
Hostgruppen-Zuweisungen je Mitglied auf (P vs. P·G) und macht nicht
synchrone Zustaende ohne Farbe erkennbar.
Die Matrix plant nur: Zuweisen und Entfernen laufen ueber die
vorhandenen Aktionen, ausgerollt wird weiter per Dry-Run auf der
Schluesselseite. Der Aufbau ist eine reine Funktion in src/lib, damit
Seite und CSV-Export garantiert dasselbe zeigen und die
Gruppenaufloesung ohne Datenbank testbar ist. Der CSV-Export entschaerft
Formelbeginne, weil Schluesselnamen frei waehlbar sind und Excel sie
sonst ausfuehren wuerde.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ein Durchgang fuer den Kern-Anwendungsfall: Vorlage und Zweck, Host A,
Host B mit Zielbenutzer, Zusammenfassung, dann Schluessel erzeugen,
Benutzer anlegen, zuweisen, Dry-Run, ausrollen und Verbindung testen.
Die Vorlage Deployment-Zugang fuellt deploy, Ablaufdatum, from= und
Alias vor; bei root als Ziel warnt der Assistent ausdruecklich.
Die Ausfuehrung ist wiederaufnehmbar: wird mittendrin eine frische
Bestaetigung fuer das Zielkonto noetig, geschieht sie in einem neuen
Tab, und nichts wird doppelt angelegt. Zielkonten laufen als eigene
Vorgaenge (neue Migration) und merken sich, ob sshkv den Benutzer
angelegt hat - nur dann loescht ein Widerruf ihn spaeter.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Der Service war nur ueber die reinen Pruefregeln abgedeckt. Die
DB-Tests halten fest, was die Oberflaeche voraussetzt: doppelte Namen
melden sich am Feld name, Aenderungen protokollieren genau die
geaenderten Felder, eingebaute Vorlagen lassen sich nicht archivieren.
Der E2E-Ablauf prueft Feldfehler, Vorschau und Rechte im gebauten
Stand; die Screenshots dienen der Layout-Abnahme bei 390 px.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Auf der Seite eines Schluessels: Public Key einem Host oder einer
Gruppe zuweisen, Private Key (nur Admin) auf einen Quell-Host legen -
mit ~/.ssh/config-Eintrag und dem Host-Key des Ziels in known_hosts -,
Dry-Run fuer alle Ziele, anwenden und die Verbindung von A nach B
testen. Der Kern-Anwendungsfall laeuft damit im Browser durch (E2E).
Der Dry-Run nimmt Private-Key-Ziele nur fuer Admins auf: sonst koennte
ein Operator einen vorbereiteten Private Key ausrollen lassen. Die
Vorschau zeigt je Datei die Aktion; der Inhalt eines Private Keys
erreicht den Browser nie.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Admins koennen einen gespeicherten Private Key nach frischer
Bestaetigung einmalig anzeigen oder als Datei <slug> herunterladen und
ihn endgueltig aus SSHKeyVault loeschen.
Warum so:
- Der Web-Prozess hat keinen Master-Key. Er bittet den Worker per
Vorgang, den Key zu oeffnen; der legt ihn mit SSHKV_APP_SECRET
verschluesselt in Vorgang.ergebnis ab. Das Web holt ihn genau einmal
ab: ein einziges UPDATE unter Zeilensperre liest und ueberschreibt.
- Nicht abgeholte Keys verfallen nach zwei Minuten: Worker-Takt alle
30 s, Aufraeumen vor jeder Abholung, und das Web gibt aeltere nicht
mehr heraus. Die Status-Schnittstelle zeigt nur "bereit".
- Download nur per POST (ein GET-Link oder Vorabruf wuerde die
Abholung verbrauchen), no-store, Herkunft per Sec-Fetch-Site, weil
no-referrer bei Formular-POSTs Origin: null sendet.
- Loeschen laeuft als Worker-Vorgang, damit nur geheimnisse.ts die
Chiffrat-Felder anfasst; eigenes Recht privateKeyLoeschen mit
Bestaetigung. Deployment-Keys gibt sshkv weder heraus noch loescht es
sie.
- Protokoll: angefordert, angezeigt, heruntergeladen, geloescht - mit
Fingerprint, nie mit Key.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Personen lassen sich anlegen, bearbeiten und archivieren; ihr Detail
zeigt ihre Schluessel. Unter "Meine Schluessel" hinterlegt jede Rolle
eigene Public Keys (Freigabe Frage 4), wirksam erst nach Zuweisung
durch einen Operator oder Admin.
Warum so:
- Die eigene Person entsteht beim ersten Aufruf oder wird verknuepft:
per benutzerId, sonst per E-Mail - aber nur, wenn der OIDC-Anbieter
die Adresse bestaetigt hat. Dafuer merkt sich Benutzer jetzt
emailBestaetigt (Migration); sonst koennte jemand mit selbst
gewaehlter Adresse die Keys einer fremden Person sehen.
- Die Self-Service-Services nehmen nur den angemeldeten Benutzer und
leiten die Person selbst ab; fremde Schluessel-IDs gelten als nicht
vorhanden.
- Entfernen nur fuer eigene, selbst hinterlegte Keys ohne Verwendung,
bedingt geloescht, damit eine gleichzeitige Zuweisung nicht per
Cascade verschwindet.
- Archivieren statt Loeschen: wer bis wann welchen Key hatte, bleibt
nachvollziehbar.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Schluessel werden jetzt verwaltet statt nur im Prototyp gezeigt: Liste
mit Filter, Anlegen (erzeugen oder importieren), Detail nach dem
Prototyp aus #002, Bearbeiten der Metadaten und Download <slug>.pub.
Warum so:
- Erzeugen und Import eines Paars laufen als Vorgang im Worker, weil
nur er den Master-Key hat. Passphrase und importierter Private Key
reisen wie das Bootstrap-Passwort mit SSHKV_APP_SECRET verschluesselt
im Job, nie in Vorgang.eingabe; der Worker loescht den Job danach.
- Ein reiner Public Key ist kein Geheimnis und wird direkt im Web
angelegt, mit verstaendlicher Meldung bei einem Duplikat.
- Das Web liest nie das Chiffrat: ob ein Private Key gespeichert ist,
verraet masterKeyVersion (per CHECK an das Chiffrat gekoppelt). Ein
struktureller Test verlangt fuer jede zeilenliefernde Abfrage auf
Schluessel ausserhalb des Workers ein festes select.
- Migration: Vorgangsarten fuer Erzeugen, Import und (fuer #014) das
Loeschen des Private Keys; CHECKs fuer den Slug (landet in
Dateinamen) und "geloescht nur ohne Chiffrat".
- Platzhalter PublicAusrollenAktion/PrivateAusrollenAktion fuer #016/#017.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Gebauter Stand mit Worker gegen das Testziel: Host einrichten, Dry-Run
zeigt das Diff, auf dem Host aendert sich noch nichts, nach dem
Anwenden steht der Key mit seinen Einschraenkungen im Block.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Auf der Hostseite: Host-Key abrufen, Fingerprint vergleichen und
vertrauen oder ablehnen. Weicht ein Key vom vertrauten ab, erscheint
eine deutliche Warnung, und Annehmen geht nur mit Haekchen und frischer
Bestaetigung. Danach Bootstrap per Einmal-Passwort oder per Befehl und
Verbindungspruefung, jeweils mit Fortschrittsanzeige.
Der sshd-Befund empfiehlt prohibit-password, wenn root sich per
Passwort anmelden darf - nur als Hinweis, geaendert wird nichts.
E2E im gebauten Stand mit Worker gegen ein echtes sshd.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Anmeldung, Einrichtung des zweiten Faktors fuer den Notfall-Admin,
erneute Bestaetigung vor kritischen Aktionen und die Seite fuer
fehlende Rechte. Die Huelle zeigt jetzt den echten Benutzer, und jede
Seite prueft die Sitzung selbst; ein struktureller Test haelt das fest.
Die Ablaeufe sind im gebauten Stand gegen den Mock-OIDC geprueft
(pnpm test:e2e): Admin, Konto ohne Gruppe, Notfall-Admin mit TOTP.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
florian.wilde
