Auf mehrfachen Wunsch einer Person beschreibe ich hier einmal, wie ich Vaultwarden selbst hoste. Vaultwarden ist eine nicht offizielle auf Open Source basierende Serverkomponente, mit der sich jeder Bitwarden-Client verbinden lässt. Bitwarden ist der Passwort-Manager, den ich verwende, dazu vielleicht später einmal mehr. Nur so viel an dieser Stelle, der Client ist ebenfalls Open-Source-Software. Er existiert für nahezu jede Plattform und als Plugin / Extension / Addon für die gängigen Browser.
Zunächst habe ich einen User angelegt, unter dem die Serverkomponente laufen soll. Bei mir heisst der User vault.
$ groupadd --gid 201 vault
$ useradd -u 201 -s /bin/bash -g vault -m -k /etc/skel -b /srv vault
Bei mir wird eine Fehlermeldung geworfen, weil die User-ID nicht in der vorgegebenen Range ist, ich ignoriere die. Wenn es Euch wichtig ist, nutzt eine andere ID.
Das Homeverzeichnis des Users liegt unter /srv/vault, wo später auch die Daten liegen werden.
Ich weiss, dass das alles mit Quadlets geht, mir geht aber in der Experimentierphase das ständige Daemon-Reload auf die Nerven, daher wird der Dienst bei mir mit Skripten gestartet und gestoppt und mit dem folgenden systemd-Unit-File automatisiert.
$ cat /etc/systemd/system/vault.service
[Unit]
Description=Vaultwarden
Documentation=https://github.com/dani-garcia/vaultwarden
Requires=network-online.target
After=network.target
[Service]
Restart=on-failure
User=vault
Group=vault
Type=simple
WorkingDirectory=/srv/vault
ExecStart=/srv/vault/start.bash
ExecStop=/srv/vault/stopp.bash
[Install]
WantedBy=multi-user.target
Ach ja, um über Port 443 erreichbar zu sein, benötigen wir noch einen Reverse-Proxy. Da hat sich bei mir Caddy bewährt. Der Eintrag im Caddyfile ist gerade einmal drei Zeilen lang. Caddy sorgt automatisiert für Let's Encrypt-Zertifikate.
$ cat /etc/caddy/Caddyfile
vault.deine.domain {
reverse_proxy localhost:3201
}
Nach einem Wechsel auf den User vault (su - vault), erstelle ich ein Verzeichnis data und lege die Skripte start.bash und stopp.bash an und mache sie ausführbar. Die "set -o"-Einträge habe ich grundsätzlich in Skripten. Ich benutze Podman für Container und nicht Docker.
Um den Container starten zu können, braucht man noch ein paar User-IDs und die Möglichkeit, dass der Dienst auch laufen kann, wenn der User nicht angemeldet ist. Dass die Zeilen so aussehen, ist reiner Bequemlichkeiteit geschuldet. Da gibt es noch Tuning-Potenzial.
$ grep vault /etc/subuid
vault:100000:65536
$ grep vault /etc/subgid
vault:100000:65536
$ loginctl enable-linger vault
$ cat start.bash
#!/bin/bash
set -o errexit
set -o nounset
set -o pipefail
podman ps -a | awk '! /^CONTAINER/ {print $1}' | xargs podman rm || true
podman run --rm \
--name vaultwarden \
--env DOMAIN="https://vault.deine.domainr/" \
--volume /srv/vault/data/:/data/ \
--publish 127.0.0.1:3201:80 \
docker.io/vaultwarden/server:latest
$ cat stopp.bash
#!/bin/bash
set -o errexit
set -o nounset
set -o pipefail
podman stop vaultwarden
Nach systemctl restart caddy könnt Ihr testen.
Wenn alles richtig ist, sollte nach einer Ausführung von start.bash die Webseite von Vaultwarden aufrufbar sein und Ihr könnt einen Account anlegen. Falls nicht, müssen die Fehlermeldungen behoben werden. Wenn Ihr nicht weiterkommt, meldet Euch bitte.
Für die Automatisierung braucht es ein systemctl daemon-reload und ein systemctl enable --now vault.
Viel Spass!
Huch, vergessen, Ihr braucht ja auch noch die Adminseite unter /admin.
Dazu muss einmal das start.bash-Skript und die Zeile -e ADMIN_TOKEN= ergänzt, die Webseite unter vault.deine.domain/admin aufgerufen, Einstellungen gespeichert und die Zeile danach wieder gelöscht werden.
Achtung: Das beschriebene ist die einfache, unsichere Variante, wie man das Token sicher generiert, ist auf der Vaultwarden-Webseite beschrieben.