212 lines
15 KiB
Markdown
212 lines
15 KiB
Markdown
🛠️ Kapitel 6 – Vaultwarden (Docker, Debian‑12‑LXC) – Tutorial
|
||
|
||
Zu Beginn ein kurzer Hinweis: Grundlegendes wie die Bedienung von Nano, das Anlegen eines LXC samt SSH‑Zugang oder das Hinterlegen der Domain im Nginx Proxy Manager (NPM) haben wir bereits in den Basis‑Kapiteln ausführlich gezeigt. Hier verweisen wir darauf und konzentrieren uns auf das, was Vaultwarden besonders macht – mit Erklärungen dort, wo Entscheidungen oder Schalter wichtig sind.
|
||
|
||
—
|
||
|
||
## Ziel und Aufbau
|
||
|
||
Wir setzen Vaultwarden in einem Debian‑12‑LXC mit Docker und Docker Compose auf. Der Dienst läuft intern auf Port 80 (Web/API) und 3012 (WebSocket). NPM veröffentlicht ihn sauber unter `https://pass.DEINE‑DOMAIN.tld`, inklusive Let’s‑Encrypt‑Zertifikat sowie einer speziellen Weiterleitung des WebSocket‑Kanals. Registrierungen bleiben geschlossen; das Admin‑Backend sichern wir mit einem modernen Argon2‑Token. Am Ende weißt du nicht nur, **was** zu klicken ist, sondern auch **warum**.
|
||
|
||
—
|
||
|
||
## Voraussetzungen (knapp, aber konkret)
|
||
|
||
Der Container ist ein Debian‑12‑LXC nach unserem Grundsetup. Plane eine vCPU, 512 MB bis 1 GB RAM und 4–8 GB Platte ein. Der LXC hat eine statische IPv4 (zum Beispiel `10.0.0.16/24`). NPM läuft bereits in einem eigenen LXC, und deine Subdomain `pass.DEINE‑DOMAIN.tld` zeigt via DNS auf NPM. Im Folgenden nennen wir diese IP des Vaultwarden‑LXC `<VW_IP>`.
|
||
|
||
—
|
||
|
||
## 1) System vorbereiten
|
||
|
||
Bevor wir Docker installieren, bringen wir die Paketquellen auf Stand und installieren die kleinen Helfer, mit denen wir das offizielle Docker‑Repository sauber einbinden. Das ist transparenter und sicherer als ein Einzeiler‑Installskript.
|
||
|
||
```bash
|
||
apt update && apt upgrade -y
|
||
apt install -y ca-certificates curl gnupg lsb-release
|
||
```
|
||
|
||
—
|
||
|
||
## 2) Docker und Compose installieren
|
||
|
||
Wir fügen die signierte Docker‑Quelle hinzu, installieren Engine, CLI und das Compose‑Plugin und schalten den Dienst ein. Vorteil: schnelle Sicherheitsupdates direkt vom Projekt, und Compose ist als modernes Plugin integriert (kein separater „docker‑compose“-Binary mehr).
|
||
|
||
```bash
|
||
mkdir -p /etc/apt/keyrings
|
||
curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
|
||
|
||
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
|
||
$(. /etc/os-release && echo $VERSION_CODENAME) stable" > /etc/apt/sources.list.d/docker.list
|
||
|
||
apt update
|
||
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
|
||
systemctl enable --now docker
|
||
```
|
||
|
||
Prüfe kurz, ob alles da ist:
|
||
|
||
```bash
|
||
docker --version && docker compose version
|
||
```
|
||
|
||
Falls Docker im LXC nicht starten will, aktiviere in Proxmox beim CT „nesting“ und „keyctl“ und starte den Container neu.
|
||
|
||
—
|
||
|
||
## 3) Projekt anlegen und Konfiguration schreiben
|
||
|
||
Wir legen das Arbeitsverzeichnis `/opt/vaultwarden` samt Datenordner an. Die Konfiguration parken wir in einer `.env`‑Datei – das trennt Geheimnisse sauber von der Compose‑Datei und macht spätere Anpassungen ungefährlich.
|
||
|
||
```bash
|
||
mkdir -p /opt/vaultwarden && cd /opt/vaultwarden
|
||
mkdir -p data
|
||
nano .env
|
||
```
|
||
|
||
Füge folgenden Inhalt ein und ersetze Platzhalter (die Domain bitte **mit https** – sonst fehlen später Assets oder Links wirken „kaputt“):
|
||
|
||
```
|
||
DOMAIN=https://pass.DEINE-DOMAIN.tld
|
||
# Wir beginnen mit geschlossenen Registrierungen und öffnen sie später kurz für deinen Erstnutzer.
|
||
SIGNUPS_ALLOWED=false
|
||
# Optional: SMTP, falls du Verifizierungs- und Reset-Mails brauchst
|
||
# SMTP_HOST=smtp.example.com
|
||
# SMTP_FROM=pass@example.com
|
||
# SMTP_PORT=587
|
||
# SMTP_SECURITY=starttls
|
||
# SMTP_USERNAME=user
|
||
# SMTP_PASSWORD=deinPasswort
|
||
```
|
||
|
||
Speichern mit Strg+O, Enter, anschließend Strg+X.
|
||
|
||
—
|
||
|
||
## 4) Compose‑Datei erstellen
|
||
|
||
Die Compose‑Datei beschreibt, welches Image gestartet wird, wo Daten liegen und welche Ports wir durchreichen. Wichtig sind hier das Daten‑Volume und der zusätzliche WebSocket‑Port – ohne den gibt es keinen Live‑Sync zwischen Clients.
|
||
|
||
```bash
|
||
nano docker-compose.yml
|
||
```
|
||
|
||
```yaml
|
||
services:
|
||
vaultwarden:
|
||
image: vaultwarden/server:latest
|
||
container_name: vaultwarden
|
||
restart: unless-stopped
|
||
env_file: .env
|
||
environment:
|
||
- DOMAIN=${DOMAIN}
|
||
volumes:
|
||
- ./data:/data
|
||
ports:
|
||
- "8000:80" # Web / API
|
||
- "3012:3012" # WebSocket (Live Sync)
|
||
```
|
||
|
||
—
|
||
|
||
## 5) Starten und prüfen
|
||
|
||
Jetzt starten wir den Container im Hintergrund und schauen live in die Protokolle. So siehst du sofort, ob Vaultwarden sauber „hochkommt“, bevor du die Veröffentlichung in NPM anfasst.
|
||
|
||
```bash
|
||
docker compose up -d
|
||
docker compose logs -f --tail=80 vaultwarden
|
||
```
|
||
|
||
Wenn Zeilen wie „Rocket has launched…“ auftauchen und keine Fehlermeldungen zu `/data` erscheinen, läuft der Dienst intern – genau so wollen wir ihn vorfinden, bevor wir nach außen gehen.
|
||
|
||
—
|
||
|
||
## 6) Veröffentlichung im Nginx Proxy Manager (GUI)
|
||
|
||
Öffne die NPM‑Oberfläche und lege einen neuen Proxy Host an. In das Feld „Domain Names“ trägst du `pass.DEINE‑DOMAIN.tld` ein. Als Scheme wählst du „http“, denn NPM beendet die Verschlüsselung, und als Ziel gibst du die interne Adresse deines Vaultwarden‑Containers an: `<VW_IP>` mit Port **8000**. Die beiden Schalter „Block Common Exploits“ und „Websockets Support“ aktivierst du, damit NPM typische Angriffsversuche abfängt und der spätere Live‑Kanal technisch erlaubt ist.
|
||
|
||
Bevor du speicherst, wechselst du in den Reiter „Custom Locations“ und fügst **eine** Location hinzu. Als Pfad gibst du `/notifications/hub` ein – das ist der spezielle WebSocket‑Endpunkt, über den Vaultwarden Änderungen in Echtzeit verteilt. Als Ziel trägst du wieder `<VW_IP>` ein, diesmal aber mit Port **3012**, und aktivierst auch hier den WebSocket‑Schalter. Speichere die Location und wechsle in den Reiter „SSL“.
|
||
|
||
Dort forderst du ein neues Let’s‑Encrypt‑Zertifikat für deine Subdomain an, akzeptierst die Nutzungsbedingungen und setzt direkt **Force SSL**, **HTTP/2** und **HSTS**. Nach dem Speichern dauert es einen Moment. Anschließend rufst du im Browser `https://pass.DEINE‑DOMAIN.tld` auf. Die Login‑Seite sollte jetzt erreichbar sein; wenn du dich auf zwei Geräten anmeldest und einen Tresor‑Eintrag änderst, siehst du die Änderung ohne Neuladen – das bestätigt, dass die WebSocket‑Weiterleitung funktioniert.
|
||
|
||
—
|
||
|
||
## 7) Admin‑Backend absichern und ersten Benutzer anlegen
|
||
|
||
Beim ersten Öffnen des Admin‑Bereichs unter `https://pass.DEINE‑DOMAIN.tld/admin` meldet Vaultwarden oft, dass ein Klartext‑`ADMIN_TOKEN` unsicher ist. Das stimmt – deshalb hinterlegen wir einen **Argon2‑PHC‑Hash** in der GUI und entfernen den Klartext‑Eintrag danach aus der `.env`.
|
||
|
||
Zum Erzeugen des Hashes nutzen wir das eingebaute Werkzeug des Containers. Der Befehl fragt dich zweimal nach dem **künftigen Admin‑Passwort** (also nicht nach dem Hash). Den ausgegebenen String, der mit `$argon2id$…` beginnt, kopierst du vollständig.
|
||
|
||
```bash
|
||
docker exec -it vaultwarden /vaultwarden hash --preset owasp
|
||
```
|
||
|
||
Zurück im Admin‑Panel gehst du auf **Settings → General** und fügst den kompletten PHC‑String in das Feld „Admin token / Argon2 PHC“ ein. Nach dem Speichern verwendest du im Admin‑Login künftig das **Passwort**, das du beim Hash erzeugt hast – nicht den Hash selbst. Damit der Klartext‑Eintrag nicht mehr herumliegt, entfernst du die Zeile `ADMIN_TOKEN=` aus der `.env` und startest den Container neu:
|
||
|
||
```bash
|
||
sed -i '/^ADMIN_TOKEN=/d' /opt/vaultwarden/.env
|
||
cd /opt/vaultwarden && docker compose restart vaultwarden
|
||
```
|
||
|
||
Damit ist das Backend zeitgemäß gehärtet. Jetzt legst du deinen ersten Nutzer an: In **Settings → General** schaltest du „Allow new signups“ kurz ein und speicherst. In einem neuen Tab öffnest du `https://pass.DEINE‑DOMAIN.tld/#/register`, registrierst dein Konto, meldest dich einmal an und deaktivierst die Registrierung wieder. Wenn du bereits SMTP konfiguriert hast, kannst du alternativ über **Users → Invitations** Einladungs‑Mails verschicken.
|
||
|
||
Zum Schluss gehst du in deinem Benutzerkonto auf **Settings → Security** und aktivierst die Zwei‑Faktor‑Anmeldung (TOTP oder FIDO2/YubiKey). Das schützt deinen Tresor zusätzlich, selbst wenn jemand an dein Passwort käme.
|
||
|
||
—
|
||
|
||
## 8) Backups verstehen und durchführen
|
||
|
||
Wichtig ist nicht der Container – den kannst du jederzeit ersetzen –, sondern der **Datenordner** auf dem Host. Darin liegen Datenbank, Anhänge, „Sends“ und Konfiguration. Ein einfaches, zuverlässiges Backup besteht darin, diesen Ordner regelmäßig als Archiv zu sichern. Für maximale Konsistenz kannst du Vaultwarden vorher kurz stoppen; für kleine Umgebungen ist ein „Online‑Tar“ oft ausreichend.
|
||
|
||
```bash
|
||
cd /opt/vaultwarden
|
||
# optional: kurz stoppen für maximale Konsistenz
|
||
# docker compose stop vaultwarden
|
||
|
||
tar -czf /root/vaultwarden-backup-$(date +%F).tar.gz data
|
||
# docker compose start vaultwarden
|
||
ls -lh /root/vaultwarden-backup-*.tar.gz
|
||
```
|
||
|
||
Die Wiederherstellung ist entsprechend einfach: neue Instanz bis zur Compose‑Datei bringen, Archiv nach `/opt/vaultwarden/` kopieren, entpacken, `docker compose up -d` – fertig.
|
||
|
||
—
|
||
|
||
## 9) Vaultwarden im Alltag nutzen (Standard‑Anwendungen im Detail)
|
||
|
||
Nach der Installation geht es darum, den Tresor im Alltag bequem und sicher zu verwenden. Der Einstieg geschieht meist über die Web‑Oberfläche: Du meldest dich unter `https://pass.DEINE‑DOMAIN.tld` an und siehst zunächst einen leeren Tresor. Lege deinen ersten Eintrag an – Name, Benutzername oder E‑Mail, ein mit dem Generator erzeugtes langes Passwort und die Ziel‑URL. Das ist bewusst simpel: Einträge sind die kleinste Einheit, aus ihnen baust du dir später Ordnung und Automatik.
|
||
|
||
**Einträge anlegen & strukturieren.** Wenn du viele Zugänge hast, zahlt sich eine klare Struktur aus. Lege in der Web‑Oberfläche Ordner an (etwa „Streaming“, „Privat“, „Server“). Beim Speichern eines Eintrags weist du ihn direkt einem Ordner zu. So findest du Logins auch nach Monaten wieder, ohne suchen zu müssen. Für wiederkehrende Notizen (z. B. Seriennummern, kleine API‑Tokens) gibt es den Eintragstyp „Sichere Notiz“.
|
||
|
||
**Browser‑Erweiterung verbinden.** Installiere die Bitwarden‑Erweiterung in deinem Browser und stelle in den Einstellungen die Server‑URL auf deine Instanz (`https://pass.DEINE‑DOMAIN.tld`). Nach dem Login siehst du dieselben Einträge wie im Web‑Tresor. Aktiviere die Option, beim Aufruf einer Login‑Seite passende Einträge vorzuschlagen; wenn du möchtest, kannst du auch Auto‑Fill per Tastenkombination erlauben. Das ist besonders praktisch, wenn du häufig zwischen Diensten wechselst.
|
||
|
||
**Import bestehender Passwörter.** Viele starten nicht bei null. Der Import liegt in der Web‑Oberfläche unter „Werkzeuge → Importieren“. Wähle die Quelle (z. B. Chrome, Firefox, Bitwarden CSV/JSON), lade die Datei hoch und starte den Import. Sinnvoll ist es, zunächst einen temporären Ordner wie „Eingang“ anzulegen und dort alles hinein importieren zu lassen. Danach ziehst du Stück für Stück in deine endgültige Struktur um und löschst Dubletten. Falls eine Website Sonderregeln für Passwörter hat (nur bestimmte Zeichen), passe den betroffenen Eintrag nach dem Import an – wichtig ist, dass der in Vaultwarden gespeicherte Wert mit dem wirklich gesetzten Passwort übereinstimmt.
|
||
|
||
**TOTP/2FA in Einträgen hinterlegen.** Aktivierst du bei einem Dienst Zwei‑Faktor‑Anmeldung, bekommst du einen QR‑Code oder einen Text‑Schlüssel (Base32). In Vaultwarden öffnest du den passenden Eintrag, fügst ein neues Feld vom Typ „Authenticator‑Schlüssel (TOTP)“ hinzu und kopierst den Schlüssel hinein. Ab dann zeigt der Eintrag alle 30 Sekunden einen neuen sechsstelligen Code an, den du beim Login verwendest. Praktisch: Die Browser‑Erweiterung kann den TOTP‑Code mit ausfüllen oder mit einem Klick kopieren. Für besonders kritische Zugänge kannst du überlegen, TOTP getrennt aufzubewahren (z. B. Hardware‑Token) – Standard‑Accounts sind im Alltag mit TOTP im Tresor jedoch gut bedient.
|
||
|
||
**Autofill sinnvoll einsetzen.** Auto‑Fill spart Zeit, sollte aber bewusst konfiguriert werden. Lasse dir beim Seitenaufruf passende Einträge vorschlagen, bestätigt wird das Füllen idealerweise manuell (Klick oder Tastenkürzel). Auf gemeinsam genutzten Rechnern empfiehlt sich außerdem, die Erweiterung nach kurzer Inaktivität automatisch zu sperren und nur per Master‑Passwort, PIN oder Biometrie zu entsperren.
|
||
|
||
**„Send“: sicher teilen, was nicht im Mail‑Postfach liegen soll.** Manchmal musst du einem Kollegen schnell einen Schlüssel oder eine kleine Datei geben. Mit „Send“ erzeugst du einen geschützten Link mit Ablaufdatum und optionalem Kennwort sowie einer Begrenzung der Abrufe. Das passt gut für einmalige Übergaben, ohne dass sensible Inhalte in E‑Mails oder Chat‑Verläufen liegen bleiben.
|
||
|
||
**Gemeinsam nutzen: Organisation & Sammlungen.** Wenn ihr zu zweit oder im kleinen Team arbeitet, legst du eine Organisation an und darin „Sammlungen“ (etwa „Stream‑Zugänge“, „Server‑Logins“). Einträge, die ihr teilen wollt, verschiebst du in die passende Sammlung. Zugriffsrechte vergibst du pro Mitglied und Sammlung. Wichtig: Einladungen versendet Vaultwarden per Mail – ohne funktionierendes SMTP legst du neue Konten zunächst wie oben beschrieben über eine kurz geöffnete Registrierung an und verschiebst Einträge anschließend in Sammlungen.
|
||
|
||
**Export vs. Backup – was ist der Unterschied?** Der persönliche Export in der Web‑Oberfläche ist dafür gedacht, deinen Tresor nutzerseitig mitzunehmen (je nach Client als CSV oder verschlüsselte JSON‑Variante). Das **Server‑Backup** aus Abschnitt 8 sichert die komplette Instanz mit allen Anhängen, „Sends“ und Einstellungen. Für echte Ausfallsicherheit nutzt du beides: regelmäßige Server‑Backups und gelegentliche Exporte des eigenen Tresors.
|
||
|
||
## 10) Updates ohne Drama
|
||
|
||
Ein Update entspricht einem Image‑Tausch. Du holst das aktuelle Image und startest neu; die Daten bleiben, wo sie sind. Vorherige Backups sind trotzdem Pflicht.
|
||
|
||
```bash
|
||
cd /opt/vaultwarden
|
||
docker compose pull
|
||
docker compose up -d
|
||
```
|
||
|
||
Wenn etwas nach einem Update unerwartet läuft, Rollbackst du kurzzeitig auf den vorherigen Tag bzw. die vorherige Image‑ID und planst das Update neu – mit Blick ins Changelog.
|
||
|
||
—
|
||
|
||
## Ergebnis
|
||
|
||
Vaultwarden läuft hinter NPM unter deiner eigenen Domain mit gültigem TLS, Live‑Sync per WebSockets und gehärtetem Admin‑Backend. Registrierungen sind standardmäßig zu, dein erster Benutzer ist angelegt, und du hast ein praktisches Backup‑Verfahren. Ab hier geht es um Komfort: Add‑ons in allen Browsern, Apps auf den Geräten und ein bisschen Routine beim Generieren wirklich starker, individueller Passwörter.
|