florian.wildeandClaude Opus 5.5 edc38d0c27 feat(ausrollen): Private Key mit ssh-config und known_hosts (#017)
Der Kern-Anwendungsfall im Worker: Private Key auf Host A, Public Key
auf Host B, dazu ein Block in ~/.ssh/config von A und der vertraute
Host-Key von B in known_hosts - danach meldet sich A per Alias bei B
an, ohne Rueckfrage zum Host-Key (Integrationstest gegen zwei echte
sshd).

Gleiches Muster wie bei Public Keys: Plan je Datei mit Hashes, dann
genau dieser Plan. Der Inhalt eines Private Keys steht nie im Plan
oder Protokoll, eine fremde Datei am Zielpfad wird nie ueberschrieben,
und von einem alten Private Key bleibt keine Sicherungskopie liegen.
Der config-Block steht am Anfang, weil ssh den ersten Treffer nimmt.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-12 10:49:28 +02:00

SSHKeyVault (sshkv)

Selbst gehostete Weboberfläche zur zentralen Verwaltung von SSH-Schlüsseln: Schlüsselpaare erzeugen und verwalten, Public Keys in authorized_keys verteilen, Private Keys gezielt auf andere Hosts ausrollen, Ist- und Soll-Zustand abgleichen – alles revisionssicher protokolliert.

Stand 0.1.0 (Phase 1): Grundgerüst, Anmeldung (OIDC + Notfall-Admin mit TOTP), Hosts und Hostgruppen, Host-Key-Prüfung (TOFU) und Bootstrap neuer Hosts. Schlüsselverwaltung und Ausrollen folgen in Phase 2 und 3 – siehe docs/PLAN.md.

Sicherheit vorab

SSHKeyVault hat root-Zugriff auf alle verwalteten Hosts. Deshalb:

  • nur im internen Netz bzw. VPN betreiben, mit Reverse Proxy und TLS davor;
  • den Master-Key (SSHKV_MASTER_KEY_FILE) getrennt von der Datenbank sichern – ohne ihn ist ein Datenbank-Backup wertlos, und mit ihm zusammen gibt es alle Private Keys preis;
  • Private Keys liegen nur verschlüsselt in der Datenbank (AES-256-GCM, Envelope Encryption); entschlüsseln kann ausschließlich der Worker, der Webprozess hat den Master-Key nicht.

Mehr dazu in docs/PLAN.md, Abschnitt 3.

Installation (Docker Compose)

cp .env.example .env              # Werte eintragen, siehe Kommentare
openssl rand -base64 48           # → SSHKV_APP_SECRET
mkdir -p geheim && head -c 32 /dev/urandom > geheim/master.key
sudo chown 1001:1001 geheim/master.key && sudo chmod 400 geheim/master.key
docker compose up -d

Die Oberfläche lauscht auf 127.0.0.1:3400 (SSHKV_BIND, SSHKV_PORT). Beim ersten Start legt der Dienst migrate das Schema, den Notfall-Admin (SSHKV_BREAKGLASS_*) und die eingebauten Vorlagen an; der Worker erzeugt den Deployment-Key der Instanz.

Anmeldung: über authentik (SSHKV_OIDC_*, Rollen über die Gruppen sshkv-admins, sshkv-operators, sshkv-readers). Der Notfall-Admin richtet bei der ersten Anmeldung TOTP ein.

Einen Host aufnehmen

  1. Hosts → + Host anlegen (Name, Adresse, Port; Anmeldung als Dienstbenutzer sshkv mit sudo – empfohlen – oder direkt als root).
  2. Host-Key abrufen, den Fingerprint am Host vergleichen (ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub) und vertrauen.
  3. Bootstrap: einmalig per Passwort (wird nicht gespeichert) oder den angezeigten Befehl auf dem Host einfügen und „Einrichtung prüfen“.

Entwicklung

Node 24, pnpm 12, Docker. Konventionen und Befehle: CLAUDE.md.

pnpm install
pnpm db:up && pnpm db:migrate && pnpm db:seed
pnpm test:ziele:up                # SSH-Testziele + Mock-OIDC
pnpm build && pnpm start          # http://localhost:3400
pnpm worker                       # zweites Terminal
pnpm test && pnpm test:integration && pnpm test:e2e
S
Description
No description provided
Readme
12 MiB
Languages
TypeScript 98.4%
Shell 0.6%
JavaScript 0.4%
HTML 0.2%
Dockerfile 0.2%
Other 0.2%