Homelab--Bratonein-Kontrollzentrum--Tutorial/Tutorial.md at 94aff0580ee6bc93f8a2483d84daeb917da1be78

Thomas/Homelab--Bratonein-Kontrollzentrum--Tutorial

Fork 0

Files

Thomas Dannenberg 94aff0580e Kapitel 6/Tutorial.md aktualisiert

2025-08-20 10:36:12 +00:00

10 KiB

Raw Blame History

📝 Kapitel 6 – Vaultwarden (ohne Docker, systemd)

🎯 Was wir bauen (in Klartext)

Wir richten Vaultwarden als Passwort‑Tresor ein. Das ist die kompatible Server‑Variante zu Bitwarden. Du bekommst:

eine Web‑Oberfläche zum Verwalten deiner Passwörter und TOTP‑Codes,
sichere Anmeldung (Admin‑Token, Registrierungen aus),
HTTPS über den Nginx Proxy Manager (NPM) und
Live‑Sync dank WebSockets.

Wir betreiben Vaultwarden ohne Docker (direkt als Programm), damit es möglichst wenig RAM verbraucht.

✅ Voraussetzungen (kurz & klar)

LXC‑Container: Debian 12 (Bookworm) – erstellt nach dem Grundkapitel Erster LXC – Grundsetup & SSH. (Hier nicht wiederholt.)
LXC‑Spezifikation für dieses Kapitel: 1 vCPU · 256 MB RAM · 4 GB Disk · statische IPv4 (z. B. 10.0.0.16/24). IPv6 optional (SLAAC oder None). DNS wie im Netz üblich.
Nginx Proxy Manager läuft (eigenes Kapitel), Domain vorhanden (z. B. pass.DEINE-DOMAIN.tld).

Platzhalter, die du gleich ersetzt:

<VW_IP> → IP deines Vaultwarden‑LXC, z. B. 10.0.0.16
DEINE-DOMAIN.tld → deine echte Domain

1) System vorbereiten

Wir aktualisieren das System, installieren Werkzeuge und richten einen eigenen Dienst‑Benutzer ein.

Warum ein eigener Dienst‑Benutzer? Dieser Benutzer ist nur für den Vaultwarden‑Dienst da (kein normales Login). Dadurch sind die Tresor‑Dateien vor anderen Diensten geschützt. In früheren Docker‑Kapiteln war diese Trennung im Container bereits vorhanden – jetzt übernehmen wir sie auf Systemebene.

apt update && apt upgrade -y
apt install -y ca-certificates curl unzip openssl

# Dienstnutzer ohne Login anlegen (nur für den Dienst, zur Absicherung)
useradd --system --home /var/lib/vaultwarden --shell /usr/sbin/nologin vaultwarden || true

# Arbeits- und Datenordner anlegen
mkdir -p /opt/vaultwarden
mkdir -p /var/lib/vaultwarden/data

# Eigentum der Daten an den Dienstbenutzer übergeben (Schutz der Tresor-Daten)
chown -R vaultwarden:vaultwarden /var/lib/vaultwarden

So prüfst du das Ergebnis:

id vaultwarden
ls -ld /opt/vaultwarden /var/lib/vaultwarden /var/lib/vaultwarden/data

Du siehst den Benutzer vaultwarden und die Ordner existieren.

2) Vaultwarden herunterladen (robust & sicher)

Wir laden immer die neueste stabile Release passend zu deiner CPU‑Architektur – automatisch und mit Fehlerschutz.

set -Eeuo pipefail

# Architektur → passender Dateiname der Release-Asset
case "$(dpkg --print-architecture)" in
  amd64)  ASSET="vaultwarden-*-x86_64-unknown-linux-gnu.tar.gz" ;;
  arm64)  ASSET="vaultwarden-*-aarch64-unknown-linux-gnu.tar.gz" ;;
  armhf|armel) ASSET="vaultwarden-*-armv7-unknown-linux-gnueabihf.tar.gz" ;;
  *) echo "❌ Nicht unterstützte Architektur: $(dpkg --print-architecture)" >&2; exit 1 ;;
 esac

# jq für zuverlässiges JSON-Parsing (klein, darf wieder entfernt werden)
apt install -y jq >/dev/null

# 1) Download-URL der neuesten stabilen Release exakt ermitteln
VW_URL=$(curl -fsSL https://api.github.com/repos/dani-garcia/vaultwarden/releases/latest \
  | jq -r --arg pat "$ASSET" '.assets[] | select(.name | test($pat)) | .browser_download_url' \
  | head -n1)

if [ -z "${VW_URL}" ]; then
  echo "❌ Konnte die Download-URL nicht ermitteln. Prüfe Internet/DNS/GitHub-API-Limit." >&2
  echo "ℹ️  Alternativ: Öffne die Release-Seite im Browser und kopiere den Link der Datei $ASSET." >&2
  exit 1
fi

echo "→ Lade: $VW_URL"

# 2) Archiv laden und entpacken
curl -fL "$VW_URL" -o /tmp/vaultwarden.tar.gz
mkdir -p /tmp/vw
 tar -xzf /tmp/vaultwarden.tar.gz -C /tmp/vw

# 3) Programmdatei nach /opt verschieben
install -m 0755 /tmp/vw/vaultwarden /opt/vaultwarden/vaultwarden

# Optional: Checksumme anzeigen (mit der Release-Seite vergleichen)
sha256sum /tmp/vaultwarden.tar.gz | awk '{print "SHA256:", $1}'

Erfolgskontrolle

/opt/vaultwarden/vaultwarden --version

Du siehst die Version der frisch installierten Release.

Warum diese Variante?

Wählt die richtige Architektur automatisch aus (x86_64/arm64/armv7).
Nutzt die offizielle GitHub‑API mit sauberem Parsing (jq), keine fragilen grep‑Spielereien.
Bricht bei Fehlern sofort ab (set -e), damit kein halbfertiges Setup entsteht.

🆙 Späteres Update: Diesen Block erneut ausführen (er lädt die aktuelle Release) und danach systemctl restart vaultwarden. Wenn sich die Oberfläche/Optionen geändert haben, ergänzen wir einen Hinweis im Video und aktualisieren den Post.

3) Konfigurationsdatei mit Nano erstellen

Wir hinterlegen Domain, Admin‑Token, Ports und WebSockets in einer .env‑Datei. Diese Datei liest der Dienst später automatisch ein.

Sicheres Admin‑Token erzeugen (kopieren, wir fügen es gleich ein):

openssl rand -base64 48

Datei mit Nano öffnen:

nano /etc/vaultwarden.env

Folgenden Inhalt einfügen und Platzhalter ersetzen:

DOMAIN=https://pass.DEINE-DOMAIN.tld
ADMIN_TOKEN=HIER_DEIN_ERZEUGTES_TOKEN_EINFÜGEN
SIGNUPS_ALLOWED=false
WEBSOCKET_ENABLED=true

# Der Dienst lauscht auf der IP deines LXC (so erreicht NPM ihn)
ROCKET_ADDRESS=<VW_IP>
ROCKET_PORT=8000

# WebSocket-Endpunkt für Live-Sync
WEBSOCKET_ADDRESS=<VW_IP>
WEBSOCKET_PORT=3012

# Optional: nur wenn du E-Mails (z. B. Verifizierung/Reset) willst
# SMTP_HOST=smtp.example.com
# SMTP_FROM=pass@example.com
# SMTP_PORT=587
# SMTP_SECURITY=starttls
# SMTP_USERNAME=user
# SMTP_PASSWORD=deinPasswort

Speichern in Nano: Strg+O → Enter → Beenden: Strg+X.
Datei schützen (damit nur root und der Dienst lesen dürfen):

chown root:vaultwarden /etc/vaultwarden.env
chmod 0640 /etc/vaultwarden.env

Kurz erklärt:

DOMAIN braucht https, damit Links/Icons korrekt sind.
ADMIN_TOKEN schützt das Admin‑Backend (ohne Token kommt man nicht rein).
SIGNUPS_ALLOWED=false verhindert offene Registrierungen.
ROCKET_* und WEBSOCKET_* sorgen dafür, dass der Dienst auf deiner LXC‑IP erreichbar ist und Live‑Sync funktioniert.

4) Dienstdatei (systemd) anlegen

Die Dienstdatei sagt Linux: „So startest du Vaultwarden – und bitte automatisch beim Booten.“

Datei öffnen:

nano /etc/systemd/system/vaultwarden.service

Inhalt einfügen:

[Unit]
Description=Vaultwarden (Bitwarden-compatible) – native
After=network.target

[Service]
User=vaultwarden
Group=vaultwarden
EnvironmentFile=/etc/vaultwarden.env
ExecStart=/opt/vaultwarden/vaultwarden
WorkingDirectory=/var/lib/vaultwarden

# Sicherheit (Dienst hat nur, was er braucht)
LimitNOFILE=1048576
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Speichern & schließen: Strg+O → Enter → Strg+X.
Dienst laden, aktivieren und starten:

systemctl daemon-reload
systemctl enable --now vaultwarden
systemctl status vaultwarden --no-pager

Woran erkenne ich Erfolg?

Status zeigt active (running).
Optional: Ports prüfen

ss -tulpn | grep -E ':8000|:3012'

Was haben wir gerade gemacht?

Den Dienst systemweit registriert und dauerhaft aktiviert.
Vaultwarden läuft jetzt im Hintergrund – automatisch auch nach Neustarts.

5) NPM einrichten (Proxy, WebSockets, Zertifikat)

So wird deine Instanz über HTTPS erreichbar und Live‑Sync funktioniert.

Proxy Host anlegen
- Domain Names: pass.DEINE-DOMAIN.tld
- Scheme: http
- Forward Hostname / IP: <VW_IP>
- Forward Port: 8000
- Block Common Exploits: ✔️
- Websockets Support: ✔️
Custom Location hinzufügen
- Location: /notifications/hub
- Forward Hostname / IP: <VW_IP>
- Forward Port: 3012
- Websockets Support: ✔️
SSL aktivieren (Let’s Encrypt)
- Request a new SSL Certificate
- Force SSL, HTTP/2, HSTS: ✔️

Test: Rufe https://pass.DEINE-DOMAIN.tld im Browser auf → Loginseite sichtbar.

Was passiert hier?

NPM nimmt Anfragen aus dem Internet an (443) und leitet sie an deinen Dienst weiter.
Die Custom Location sorgt dafür, dass der WebSocket‑Kanal (Live‑Sync) funktioniert.

6) Erstkonfiguration im Browser

Admin‑Backend öffnen: https://pass.DEINE-DOMAIN.tld/admin → Admin‑Token eingeben.
Registrierung prüfen: „Signups allowed“ ist aus (kommt aus deiner .env).
Optional SMTP eintragen und Testmail senden.
Erstes Benutzerkonto anlegen und 2FA (TOTP oder FIDO2) aktivieren.

Warum?

So bleibt der Server privat (nur du legst Accounts an).
2FA schützt deinen Tresor zusätzlich.

7) Backup (Basis, schnell & sicher)

Wir sichern den Datenordner. Damit kannst du den Tresor später wiederherstellen.

# Für maximale Konsistenz könntest du kurz stoppen (optional)
# systemctl stop vaultwarden

tar -czf /root/vaultwarden-backup-$(date +%F).tar.gz -C /var/lib vaultwarden
# systemctl start vaultwarden
ls -lh /root/vaultwarden-backup-*.tar.gz

Wichtig: Plane das als Cron‑Job ein und teste gelegentlich das Restore auf einer Test‑VM.

🛠️ Wenn etwas nicht klappt

Seite lädt, aber kein Live‑Sync: In NPM die Custom Location /notifications/hub prüfen (Port 3012, WebSockets ✔️).
Icons/Links seltsam: In /etc/vaultwarden.env muss DOMAIN mit https beginnen.
Ich komme nicht ins Admin‑Backend: Stimmt das ADMIN_TOKEN noch? (Zur Not neues Token in der .env setzen und systemctl restart vaultwarden.)
Dienst startet nicht:
```
journalctl -u vaultwarden -b --no-pager | tail -n 50
```
Die letzten Zeilen zeigen meistens den Fehler (z. B. Tippfehler in der .env).

✅ Ergebnis

Deine Instanz ist über https://pass.DEINE-DOMAIN.tld erreichbar.
Registrierungen sind aus, Admin‑Backend ist durch Token geschützt.
WebSockets funktionieren (Live‑Sync zwischen Geräten).
Backups sind eingerichtet.

Du hast jetzt einen schlanken, eigenen Passwort‑Server – ohne Docker‑Overhead, mit klaren Sicherungen und Updates.

10 KiB Raw Blame History Unescape Escape