Zum Inhalt

Vaultwarden Passwortmanager

Stand: 2026-05-30

Zweck

Vaultwarden ist der zentrale Passwortmanager für Lanstyle-Zugangsdaten, API-Keys und Service-Credentials. Ziel ist, Secrets nicht mehr in Markdown, Chatverläufen, Shell-Historien oder Git-Repositories zu verteilen.

OpenCode Self-Service Secrets

OpenCode Self-Service erzeugt pro Benutzer/Geraet eigene LiteLLM- und MCP-Tokens. Vaultwarden bleibt der organisatorische Source of Truth fuer Ownership, Ablauf und Rotation.

Regeln:

  • Tokenwerte werden nicht in Markdown dokumentiert.
  • Status- und Admin-Ansichten zeigen nur Fingerprints.
  • Neue Tokenwerte werden nur einmalig als opencode.env oder ZIP ausgeliefert.
  • Bei Verlust wird rotiert, nicht erneut angezeigt.
  • Legacy-/Bootstrap-Tokens bleiben getrennt und duerfen nicht an normale Benutzer verteilt werden.

Empfohlene Vaultwarden-Ablage pro Benutzer:

  • Ordner: Lanstyle / OpenCode Access
  • Name: OpenCode Operator <vorname-nachname-device>
  • Felder: Besitzer, Geraet, Scope, Ablauf, Fingerprint, Rotation Policy
  • Secret-Felder: LiteLLM Virtual Key, LANSTYLE_MCPHUB_TOKEN

Hermes Secrets

Stand 2026-05-29: Hermes-Secrets fuer lanstyle-hermes-01 wurden in Vaultwarden abgelegt. Secretwerte werden nicht in Git, Markdown oder Chat ausgegeben.

Einträge:

  • Lanstyle / Hermes Service Token / lanstyle-hermes-01
  • Lanstyle / Hermes Service Secret / lanstyle-hermes-01
  • Lanstyle / Hermes OpenWebUI Integration Secret / lanstyle-hermes-01
  • Lanstyle / SSH Public Key / Maximilian Eberhardt

Für Nous Hermes Core zusätzlich vorgesehen und nach sicherem Vaultwarden-Unlock zu verifizieren:

  • Lanstyle / Nous Hermes Core API / lanstyle-hermes-01
  • Lanstyle / Nous Hermes LiteLLM Routing / lanstyle-hermes-01
  • Lanstyle / Nous Hermes Qdrant Memory / lanstyle-hermes-01

Die Qdrant-Memory-Integration nutzt die Collection lanstyle_obsidian_memory. Der Qdrant-Key liegt ausschließlich in Runtime-Secret/Vaultwarden und darf nicht in Obsidian, Qdrant-Payloads, Markdown oder Logs auftauchen.

Rotation:

  1. Neues Secret auf lanstyle-hermes-01 erzeugen.
  2. /etc/hermes/hermes.env aktualisieren und hermes-agent.service gezielt neu starten.
  3. Vaultwarden-Eintrag aktualisieren.
  4. /ready, authentifizierten Testcall und Audit prüfen.
  5. Altes Secret nicht weiterverwenden.

Voice Device Secrets

Für spätere Voice-Terminals wird pro Gerät ein eigener Eintrag empfohlen:

  • Name: Lanstyle / Hermes Voice Device / <device-name>
  • Felder: device_id, owner, tenant, role, token_fingerprint, expires_at
  • Secret-Feld: Device-/Hermes-Bearer-Token

Tokens dürfen nicht in Images, Kiosk-Profilen, Markdown oder Tickets abgelegt werden.

Provider-Platzhalter:

  • Lanstyle / Hermes Voice STT Provider
  • Lanstyle / Hermes Voice TTS Provider
  • Lanstyle / Hermes Voice Device / maximilian-mac

Anthropic- oder ElevenLabs-Keys werden nicht direkt im Hermes-Code genutzt. Falls ein externer Provider später freigegeben wird, liegt der Key ausschließlich in Vaultwarden und wird über einen kontrollierten Runtime-Secret-Flow provisioniert.

Nous Hermes Core Secrets

Der Nous Hermes Core nutzt einen eigenen internen API-Server-Key und LiteLLM-Routing. Secretwerte liegen nicht in Markdown, Chat oder Logs.

Runtime-Orte:

  • /etc/nous-hermes/nous-hermes.env, 0640 root:hermes-agent
  • /var/lib/nous-hermes/.env als Symlink auf die geschuetzte Runtime-Env

Rotation:

  1. Neuen Core-API-Key erzeugen.
  2. /etc/nous-hermes/nous-hermes.env und Gateway-Referenz in /etc/hermes/hermes.env aktualisieren.
  3. nous-hermes-core.service und danach hermes-agent.service gezielt neu starten.
  4. /health, /v1/models und /voice/message testen.
  5. Vaultwarden-Fingerprint und Rotation History aktualisieren.

Ist-Konfiguration

Feld Wert
CTID 258
Hostname vaultwarden
IP 10.222.40.33/20
Gateway 10.0.0.1
Bridge vmbr0
Storage local-zfs
OS Debian 13
Typ unprivileged LXC
Ressourcen 4 vCPU, 6144 MiB RAM, 20 GB Disk
Interner Port 8000
Interne URL https://10.222.40.33:8000
Externe URL https://vault.lanstyle.de
Reverse Proxy Nginx Proxy Manager

Installation

Vaultwarden wurde per offiziellem Community-Script installiert:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/vaultwarden.sh)"

Verwendete Optionen:

  • CTID: 258
  • Hostname: vaultwarden
  • IP: 10.222.40.33/20
  • Gateway: 10.0.0.1
  • Debian 13
  • unprivileged LXC
  • 4 vCPU
  • 6144 MiB RAM
  • 20 GB Disk
  • SSH Public Key für Root hinterlegt

Der Build kompiliert Vaultwarden nativ mit Rust und dauerte etwa 11 Minuten.

Dienststatus

Geprüft:

  • vaultwarden.service ist aktiv.
  • Vaultwarden lauscht auf 0.0.0.0:8000.
  • https://10.222.40.33:8000 liefert HTTP 200.
  • https://vault.lanstyle.de liefert über NPM HTTP 200.

Konfiguration

Zentrale Konfigurationsdatei:

/opt/vaultwarden/.env

Gesetzte produktive Grundwerte:

  • DOMAIN=https://vault.lanstyle.de
  • ROCKET_ADDRESS=0.0.0.0
  • ROCKET_PORT=8000
  • WEB_VAULT_ENABLED=true
  • SIGNUPS_ALLOWED=true
  • SIGNUPS_DOMAINS_WHITELIST=lanstyle.de
  • INVITATIONS_ALLOWED=true
  • SHOW_PASSWORD_HINT=false
  • IP_HEADER=X-Forwarded-For
  • SMTP_HOST=10.0.0.3
  • SMTP_PORT=25
  • SMTP_SECURITY=off
  • SMTP_FROM=vault@lanstyle.de
  • SMTP_FROM_NAME="Lanstyle Vaultwarden"
  • ORG_CREATION_USERS=m.eberhardt@lanstyle.de

Der Admin-Token liegt nicht in Git oder Doku. Er wurde root-only im Container abgelegt:

/root/vaultwarden-admin-token.txt

Login und Admin-Zugriff

Normale Weboberfläche:

https://vault.lanstyle.de

Primärer Benutzer:

m.eberhardt@lanstyle.de

Das Masterpasswort für m.eberhardt@lanstyle.de wird nicht in diesem Repository dokumentiert. Es liegt im Apple iCloud Passwort-Safe.

Admin-Oberfläche:

https://vault.lanstyle.de/admin

Der Admin-Token ist kein Benutzerpasswort, sondern nur für die Vaultwarden-Administration gedacht. Abruf über Proxmox:

pct exec 258 -- cat /root/vaultwarden-admin-token.txt

Abruf vom Mac über SSH zum Proxmox-Host:

ssh root@10.0.0.220 'pct exec 258 -- cat /root/vaultwarden-admin-token.txt'

Der Token darf nicht in Chatverläufen, Tickets, Markdown-Dateien, Git oder Shell-Skripten abgelegt werden. Nach Nutzung möglichst aus Zwischenablage und Terminal-Scrollback entfernen.

Backups

Vor Konfigurationsänderungen wurden Backups angelegt:

  • /root/config-backups/20260520-161435
  • frühere Konfigurationsbackups unter /root/config-backups/*

Für den Regelbetrieb sichern:

  • /opt/vaultwarden/data
  • /opt/vaultwarden/.env
  • /root/vaultwarden-admin-token.txt

Empfohlene Struktur

Organisation:

  • Lanstyle IT Solutions GmbH

Collections:

  • Lanstyle / Infrastruktur
  • Lanstyle / AI-Stack
  • Lanstyle / API-Keys
  • Lanstyle / SMTP und Mail
  • Kunden / TecMed
  • Kunden / Schulen
  • Kunden / Weitere
  • Privat / Eberhardt

Automatisierung

Vaultwarden ist Bitwarden-kompatibel. Automatisierung soll über die Bitwarden CLI erfolgen:

bw config server https://vault.lanstyle.de
bw login --apikey
umask 077
BW_SESSION_FILE="${XDG_RUNTIME_DIR:-/tmp}/bw-session-$(id -u)"
bw unlock --raw > "$BW_SESSION_FILE"
export BW_SESSION
read -r BW_SESSION < "$BW_SESSION_FILE"
bw sync
bw get item "OpenAI API Key"

Die Session-Datei muss 0600 sein, darf nicht in Backups oder Logs landen und wird nach der Wartung mit bw lock plus Entfernen der Session-Datei geschlossen.

Im Projekt liegt ein Helper-Script:

scripts/lanstyle-secret

Der Helper erwartet eine installierte Bitwarden CLI und eine aktive BW_SESSION.

Für den kontrollierten Import lokal gefundener Secrets gibt es zusätzlich:

scripts/vaultwarden-import-local-secrets

Der Importer läuft standardmäßig als Dry-Run und gibt keine Secret-Werte aus. Erst mit --import werden Kandidaten in Vaultwarden angelegt. Die Filter schließen bekannte Fehlimporte aus, darunter Beispielwerte, Lockfiles, Code-Ausdrücke wie os.getenv(...) oder process.env, Metafelder wie password_hash und Variablennamen ohne echten Secret-Wert.

Bereinigungsstand vom 20.05.2026:

  • Vor der Bereinigung wurde ein Vaultwarden-Backup auf dem LXC erstellt: /root/config-backups/20260520-171645
  • Aus 67 automatisch importierten lokalen Kandidaten wurden 24 klare Fehlimporte entfernt.
  • 43 Einträge blieben erhalten, weil sie wie echte Passwörter, API-Keys, Tokens oder PSKs aussehen und bei Bedarf manuell fachlich geprüft werden sollten.
  • Der Vault wurde nach der Bereinigung wieder gesperrt.

Sortierstand vom 20.05.2026:

  • Vor dem Sortieren wurde ein verschlüsselter lokaler Bitwarden-Export erstellt: /Users/vinc32/Documents/vaultwarden-backups/vaultwarden-before-org-vault-move-20260520-173935.json
  • Echte Vaultwarden-Organisationen wurden erkannt und für die Sortierung verwendet.
  • 38 lokale Secret-Einträge wurden in Organisations-Tresore verschoben:
  • Lanstyle IT Solutions GmbH: 4 Einträge
  • Salzmannschule Schnepfenthal: 4 Einträge
  • Sportgymansium Jena: 1 Eintrag
  • Sportgymansium Oberhof: 29 Einträge
  • 5 private Einträge liegen weiterhin im persönlichen Tresor unter Organisationen/Privat/Eberhardt, weil dafür keine Organisation sichtbar war.
  • Leere persönliche Organisations-Ordner wurden nach dem Umzug entfernt.
  • Hinweis: In Vaultwarden sind die Organisationen Sportgymansium Jena und Sportgymansium Oberhof mit Tippfehler angelegt. Die technische Zuordnung verwendet derzeit diese vorhandenen Namen.

Sicherheitsregeln

  • Keine Secrets in Git, Wiki oder Skripten speichern.
  • API-Keys nach Chat-/Log-Offenlegung rotieren.
  • Für OpenCode/Open WebUI Secrets per ENV oder Admin-Settings injizieren, nicht in Projektdateien schreiben.
  • Vaultwarden nur über TLS und NPM Access List bereitstellen.
  • Admin-Token nur kurz für Administration nutzen und nicht in Browsern oder Chatverläufen speichern.