Skip to content

Vaultwarden selbst hosten

linux

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.

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Jörg am :

*Danke Dirk,
ich bin mir sicher, dies findet mehr als eine Person interessant. :-)

Ich freue mich auch schon, auf Deinen später erscheinenden Artikel zu Bitwarden.

Viele Grüße
Jörg

Dirk Deimeke am :

*;-)

Den wird es nicht geben. Da gibt es tausende von Artikeln und Videos. Da braucht es nicht noch einen weiteren.

Jörg am :

*Ich denke, Du unterschätzt das Interesse an Deiner Meinung.

Mit deinen Jahrzehnten an Berufserfahrung zählst du (schon bald) zu den Urgesteinen unsere Gemeinschaft. Deine Expertise ist auch als Autor belegt.

Ich bin sicher, dass in der Gemeinschaft ein Interesse an Deiner individuellen Perspektive und Deiner Nutzung besteht.

Viele Grüße
Jörg, der den Honig für den Bart nun beiseite stellt. ;-)

Dirk Deimeke am :

*Bitte aufpassen, Jörg, ich könnte auf der Schleimspur ausrutschen. :-D

Ich weiss wirklich nicht, was ich dazu schreiben soll, ich tue Passwörter rein und hole sie auch wieder raus. Als ssh-agent nutze ich Bitwarden nicht.

Jörg am :

*Am Boden liegend kannst du wenigstens nicht so schnell weglaufen, wenn ich weitere Fragen habe. :-P

Nutzt du Bitwarden privat und beruflich? Falls ja, mit zwei verschiedenen Tresoren? Auf allen deinen digitalen Geräten, wo dies technisch möglich ist? Oder differenzierst du da?

Die Browsererweiterungen hattest du ja schon verbloggt. Die finde ich schon wieder. ;-)

Dirk Deimeke am :

*:-D

Bitwarden nutze ich privat, beruflich setzen wir andere Tools ein.

Bitwarden ist das erste Tool, das ich auf allen technischen Geräten (Linux, Android und Windows (wir dürfen das Gerät auch privat benutzen)) und in allen Browsern (Firefox, Brave) installiere.

Ich habe drei Bitwarden-Accounts (bei Bitwarden direkt, bei tchncs.de und bei mir). Bitwarden zahle ich 10 USD pro Jahr und unterstütze damit die Weiterentwicklung.

Browsererweiterungen gibt es in den offiziellen Stores.

Zum Testen lohnt sich sicher ein kostenloser Account bei Bitwarden oder tchncs.de

Ferdinand am :

*Mittlerweile gibt es neben Vaultwarden auch Bitwarden Lite als 1-Container-Setup. Ist vielleicht eine Überlegung wert.

Dirk Deimeke am :

*Vielen Dank für die Ergänzung, Ferdinand. Das hätte ich erwähnen können (oder müssen). Hast Du damit Erfahrung?

Ferdinand am :

*Nein, Bitwarden Lite als stabile Version gibt es erst seit Dezember. Ich habe es erst kürzlich entdeckt und wollte heute eine News dazu verfassen, als ich deinen Eintrag sah. Ich nutze ebenfalls Vaultwarden und bin damit sehr zufrieden. Allerdings kann ich mir vorstellen, dass es bei Sicherheitsproblemen oder Bugs besser ist, näher dran zu sein.

Wie man im Netz lesen kann, arbeitet der Hauptentwickler von Vaultwarden jetzt bei Bitwarden, was immer das bedeuten mag.

Dirk Deimeke am :

*Ich bin mir unschlüssig. "Lite" impliziert ja einen verringerten Funktionsumfang. Vielleicht bin ich ein wenig paranoid, aber von "Open Core" zu "Closed" ist es nur ein kleiner Schritt.

Es kann sein, dass ich rosa Elefanten sehe.

Peter am :

*Hallo und vielen Dank für den Artikel. Wie kann man die Sicherheit eines solchen Systems mit einem Keepass Password Safe vergleichen? Ich überlege ob ich mir auch ein System aus Vaultwarden auf einem Raspi und der Bitwarden App installiere, ich möchte das aber nur im lokalen Netz betreiben. Ist dann so ein System in Punkto sicherheit vergleichbar mit einem Keepass Password Safe? Würde jemand in mein Netzwerk eindringen oder sonst wie den Raspi mit Valutwarden erreichen, könnte er ja auch an die Vaultwarden Daten und somit Passwörter gelangen, die Keepass Datenbank liegt auf verschiedenen Geräten wie PC, Smartphone, die Datenträger sind aber verschlüsselt. Bei Keepass ist jedes Gerät auf dem die Datenbank liegt angreifbar und somit ein Risiko, bei Vaultwarden mit Bitwarden App ist zusätzlich noch der Server ein Risiko, wenn ich bei der Konfiguration oder Wartung einen Fehler mache ehöht sich meiner Meinung nach das Risiko, oder?

Viele Grüße

Peter

Dirk Deimeke am :

*Die Angriffsfläche ist grösser, da hast Du recht, es ist ja wenigstens ein zusätzliches Gerät (der Server) beteiligt.

Natürlich sind zusätzliche Fähigkeiten nötig, um den Server abzusichern.

KeePass und Bitwarden verschlüsseln die Daten lokal, auf dem Server liegen nur Hashes.

Bei den Clients ist die Angriffsfläche das Passwort, das Du verwendest. Da kann bei KeePass ein externes Keyfile die Situation verbessern. Wichtig: extern.

Ein Einfallstor bei KeePass könnte noch die automatische Synchronisation der Passwortdatei sein.

Der Komfort ist bei Bitwarden höher.

(Ich bin kein Security-Experte).

Jörg am :

*Hallo Peter,

vorweg, wie Dirk bin ich **kein** IT-Sicherheitsexperte.

Ich möchte zu KeePass ergänzen. Wenn du eine Anwendung bzw. einen Dienst wie z.B. Nextcloud verwendest, um die KeePass-Datenbank auf mehreren Geräten zu synchronisieren, hast du ebenfalls eine Server-Komponente, die es zu sichern gilt. In diesem Fall ist die Angriffsfläche mit Bitwarden/Vaultwarden vergleichbar.

Viele Grüße
Jörg

Peter am :

*Vielen Dank für die Antworten, jetzt kann ich es besser Einschätzen ob so ein System für mich in Frage kommt.

Heute habe ich bei Heise gelesen das LetsEncrypt auch Zertifikate für IP Adressen ermöglicht die zwar nur eine kurze Laufzeit haben, aber vielleicht teste ich das mal, dann habe ich nicht die Probleme mit selbst signierten Zertifikaten, wenn Vaultwarden nur lokal betreibe.

Viele Grüße
Peter

Dirk Deimeke am :

*Wie ich schon Jörg geantwortet habe: Du kannst es ja erst mit einem kostenlosen Account einmal ausprobieren.

Eine Bitwarden-Installation kann mehrere Server benutzen.

Kommentar schreiben

Gravatar, Favatar (Favicons), Pavatar Autoren-Bilder werden unterstützt.
BBCode-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
:'(  :-)  :-|  :-O  :-(  8-)  :-D  :-P  ;-) 
Formular-Optionen
cronjob