Ist Vaultwarden sicher? Checkliste zur Absicherung

Ist Vaultwarden sicher? Die kurze Antwort

Vaultwarden ist an der wichtigsten Stelle sicher: Jedes Tresorelement wird auf Ihrem Gerät verschlüsselt, bevor es den Server erreicht. Der Server speichert Datenblöcke, die er nicht lesen kann. Selbst wer die gesamte Datenbank kopiert, benötigt das Master-Passwort, um daraus verwertbare Informationen zu gewinnen.

Diese Antwort setzt vieles voraus. Die Schwachstellen entstehen durch Ihre Konfiguration. Ein Administrationsbereich hinter einem leicht erratbaren Token. Ein Container-Port, der im gesamten Internet veröffentlicht ist. Ein Klartext-config.json. Ein Backup-Tarball im Home-Verzeichnis auf demselben System. Keines dieser Probleme betrifft die Kryptografie. Alle können dazu führen, dass selbst gehostete Tresore geleert werden.

Die folgenden Schritte setzen eine funktionierende Installation voraus. Wenn Sie noch keine haben, richten Sie sie zunächst mit der Vaultwarden-Installationsanleitung für einen VPS ein. Arbeiten Sie anschließend diese Liste der Reihe nach durch.

Was der Server tatsächlich speichert

Vaultwarden implementiert das Datenmodell von Bitwarden. Der Name, der Benutzername, das Passwort, die Notizen und die URIs eines Tresoreintrags werden im Client mit einem aus Ihrem Master-Passwort abgeleiteten Schlüssel verschlüsselt, bevor eine Anfrage gesendet wird. Der Inhalt von Anhangsdateien wird auf dieselbe Weise verschlüsselt. Der Server erhält undurchsichtige Daten mit einer UUID (universally unique identifier).

Einige Daten sind nicht verschlüsselt. Sie sollten genau wissen, um welche es sich handelt:

• Ihre E-Mail-Adresse im Klartext.
• Ihre KDF-Einstellungen (key derivation function) und das Salt, weil der Client daraus beim nächsten Login den Schlüssel erneut erzeugen muss.
• Ein serverseitiger Hash des vom Client gesendeten Master-Passwort-Hashs. Er wird zur Authentifizierung des Logins selbst verwendet.
• Metadaten: Organisationszugehörigkeit, Gerätenamen und Zeitpunkte der letzten Logins.
• Das Geheimnis für die Zwei-Faktor-Methode, die den Vaultwarden-Login schützt. Es befindet sich unverschlüsselt in der Tabelle twofactor, weil der Server den erwarteten Code berechnen und mit Ihrem Code vergleichen muss. Dabei handelt es sich nicht um ein TOTP-Secret (time-based one-time password), das Sie in einem Tresoreintrag speichern. Dieses wird wie jedes andere Feld verschlüsselt.

Der Datenordner ist klein. Bei einer Docker-Installation ist es der Ordner, den Sie auf /data gemountet haben.

sudo ls -l /vw-data/

db.sqlite3 enthält fast den gesamten Status. attachments/ enthält hochgeladene Dateien, jeweils eine pro UUID. Dies ist die einzige wichtige Datenklasse, die nicht in Datenbanktabellen gespeichert wird. sends/ enthält Send-Anhänge und ist für die vorübergehende Speicherung vorgesehen. icon_cache/ kann gelöscht werden. rsa_key.pem und die zugehörigen Dateien signieren die JWTs (JSON web tokens) angemeldeter Benutzer. Eine Kopie dieses privaten Schlüssels kann daher verwendet werden, um eine Vaultwarden-Loginsitzung zu fälschen. config.json existiert erst, wenn Sie die Admin-Seite aktivieren. Das Projekt formuliert es eindeutig: Dort werden das Admin-Token und Ihre SMTP-Zugangsdaten im Klartext gespeichert.

Das praktische Bedrohungsmodell betrifft daher den Dateisystemzugriff, nicht die Netzwerkverschlüsselung. Lesender Zugriff auf diesen einen Ordner gibt einem Angreifer die E-Mail-Adresse jedes Benutzers, dessen 2FA-Secrets, einen Schlüssel zum Fälschen von Sitzungen und eine Offline-Kopie jedes Tresors, die in Ruhe angegriffen werden kann. Jeder folgende Schritt soll verhindern, dass Unbefugte Zugriff auf diesen Ordner erhalten.

Admin-Token zuerst korrigieren

/admin ist ein vollständiges Administrationspanel: Benutzerliste, Einladungen, Löschvorgänge und sämtliche Laufzeiteinstellungen. Es wird ausschließlich durch ein gemeinsames Secret geschützt. Einen Benutzernamen gibt es nicht. Eine benutzerbezogene Zwei-Faktor-Authentifizierung gibt es ebenfalls nicht.

Ältere Anleitungen empfehlen, ADMIN_TOKEN mit openssl rand -base64 48 zu erzeugen. Das funktioniert und schreibt das Secret im Klartext in config.json und in Ihre Compose-Datei. Vaultwarden akzeptiert auch einen Argon2-PHC-String (Password Hashing Competition), sodass stattdessen ein Hash gespeichert wird. Erzeugen Sie einen solchen String in einem laufenden Container:

docker exec -it vaultwarden /vaultwarden hash

Oder ohne den laufenden Container überhaupt anzufassen:

docker run --rm -it vaultwarden/server /vaultwarden hash

Das Programm fragt zweimal nach einem Passwort und gibt anschließend eine Zeile aus, die mit $argon2id$ beginnt. Bei einer Bare-Metal-Installation führen Sie ./vaultwarden hash aus. Wenn Sie stattdessen direkt die argon2-CLI verwenden möchten, dokumentiert das Projekt die OWASP-Mindestparameter:

echo -n 'MySecretPassword' | argon2 "$(openssl rand -base64 32)" -e -id -k 19456 -t 2 -p 1

Hier liegt die Falle, die eine Stunde kosten kann. Ein PHC-String enthält zahlreiche $-Zeichen, und Docker Compose behandelt $ als Variableninterpolation. Wenn Sie den String ohne Escaping in einen environment:-Block einfügen, wird der Wert auf dem Weg zum Container verändert. Deshalb lehnt /admin ein Token ab, von dessen Richtigkeit Sie überzeugt sind. Es gibt zwei sichere Varianten. Verdoppeln Sie in docker-compose.yml jedes $:

environment:
  ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$UUZxK1FZMkZoRHFQRlVrTXZvS0E3bHpNQW55c2dBN2NORzdsa0Nxd1JhND0$$cUoId+JBUsJutlG4rfDZayExfjq4TCt48aBc9qsc3UI

In einer .env-Datei ist kein Escaping erforderlich. Verwenden Sie jedoch einfache Anführungszeichen:

ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$MmeKRnGK5RW5mJS7h3TOL89GrpLPXJPAtTK8FTqj9HM$DqsstvoSAETl9YhnsXbf43WeaUwJC6JhViIvuPoig78'

Begrenzen Sie anschließend die Anfragen an das Panel und verkürzen Sie seine Sitzung:

ADMIN_RATELIMIT_SECONDS=300
ADMIN_RATELIMIT_MAX_BURST=3
ADMIN_SESSION_LIFETIME=20

Nach drei fehlgeschlagenen Versuchen innerhalb von fünf Minuten antwortet das Panel für diesen Client nicht mehr. Die Administrationssitzung läuft nach 20 Minuten ohne Aktivität ab.

Noch besser ist es, die Seite vollständig zu deaktivieren. Die meisten Installationen benötigen sie einmal, um SMTP zu konfigurieren und die ersten Benutzer einzuladen, danach nicht mehr. Setzen Sie weder ADMIN_TOKEN noch DISABLE_ADMIN_TOKEN, entfernen Sie jeden "admin_token"-Schlüssel aus config.json und erstellen Sie den Container anschließend neu. Das Entfernen des Schlüssels aus der Datei ist wichtig, weil die Administrationsseite Einstellungen dort speichert und der Inhalt von config.json Vorrang vor der Umgebung hat. Wenn Sie nur die Variable entfernen, bleibt die Seite geöffnet.

Registrierung schließen, bevor jemand die Domain entdeckt

SIGNUPS_ALLOWED=false
SIGNUPS_VERIFY=true
SHOW_PASSWORD_HINT=false

SIGNUPS_ALLOWED ist standardmäßig auf true gesetzt. Belassen Sie diese Einstellung. Andernfalls kann jeder, der Ihre Domain erreicht, ein Konto anlegen. Seine Daten liegen dann in derselben db.sqlite3 wie Ihre Daten. Setzen Sie die Option auf false und fügen Sie Benutzer über Einladungen aus der Administrationsseite hinzu. Dafür muss SMTP funktionieren. INVITATIONS_ALLOWED ist standardmäßig ebenfalls auf true gesetzt und ermöglicht Organisationsbesitzern, andere Benutzer einzuladen. Das ist in Ordnung, wenn Sie Ihren Benutzern vertrauen. Bei einer Instanz für einen einzelnen Benutzer sollte die Option auf false gesetzt werden. Wenn nur bestimmte Domains Registrierungen erlauben sollen, ist SIGNUPS_DOMAINS_WHITELIST=example.com restriktiver als eine offene Registrierung und deutlich weniger sicher als Einladungen.

SHOW_PASSWORD_HINT ist standardmäßig auf false gesetzt und sollte so bleiben. Wenn diese Option aktiviert ist, gibt die Eingabe einer gültigen E-Mail-Adresse im Anmeldeformular den Hinweis auf das Master-Passwort des Kontos zurück. Dadurch wird sowohl der Hinweis offengelegt als auch bestätigt, dass die Adresse existiert.

Wenn Ihre Instanz längere Zeit offene Registrierungen erlaubt hat, öffnen Sie die Administrationsseite und prüfen Sie die Benutzerliste, bevor Sie davon ausgehen, dass nur Ihr eigenes Konto vorhanden ist.

Der Port, den Sie nicht veröffentlichen wollten

Das Docker-Image lauscht innerhalb des Containers auf Port 80. Bei einer Installation direkt auf dem Host ist standardmäßig ROCKET_PORT=8000 eingestellt. Der dokumentierte Startbefehl veröffentlicht den Port so:

--publish 127.0.0.1:8000:80

Der Präfix 127.0.0.1: ist entscheidend. Wenn Sie stattdessen -p 8000:80 schreiben, bindet Docker 0.0.0.0. Dazu schreibt Docker DNAT-Regeln (Destination Network Address Translation) in die Tabelle nat. Diese Regeln werden vor den filter-Chains ausgewertet, die ufw verwaltet. Deshalb meldet ufw status den Port als verweigert, während der Port aus dem Internet problemlos erreichbar ist. Eine ausführliche Erklärung des Mechanismus finden Sie im Leitfaden zu Docker-Ports, die ufw umgehen.

Prüfen Sie, worauf tatsächlich gelauscht wird:

sudo ss -tlnp | grep 8000

Ein korrektes Ergebnis ist eine einzelne Zeile, die an 127.0.0.1:8000 gebunden ist. Eine Zeile mit Bindung an 0.0.0.0:8000 bedeutet, dass der Tresor direkt erreichbar ist. Korrigieren Sie das Mapping und erstellen Sie den Container anschließend neu. Eine Port-Bindung wird beim Erstellen des Containers festgelegt, und docker compose restart ändert sie nicht:

docker compose up -d --force-recreate

In älteren Anleitungen findet sich noch ein weiterer Port: 3012, der separate WebSocket-Port. Die Unterstützung dafür wurde in Vaultwarden 1.31.0 entfernt, weil der Benachrichtigungsverkehr auf den Haupt-HTTP-Port verlagert wurde. WEBSOCKET_ENABLED und WEBSOCKET_PORT werden seit 1.29.0 ignoriert. Der aktuelle Schalter lautet ENABLE_WEBSOCKET und ist standardmäßig auf true gesetzt. Wenn Ihre Firewall oder Ihre Compose-Datei Port 3012 noch öffnet, schließen Sie ihn.

TLS am Reverse Proxy terminieren, nicht in Rocket

Vaultwarden kann TLS (Transport Layer Security) über Rocket, sein Webframework, selbst bereitstellen. Das Projekt rät davon im Produktivbetrieb ab. Die integrierte TLS-Unterstützung von Rocket bietet keine strikte SNI-Unterstützung (Server Name Indication). Deshalb lautet die Empfehlung zur Absicherung auch, die Instanz über ihren Hostnamen und niemals über eine nackte IP-Adresse aufzurufen. Öffentliche IP-Adressbereiche werden ständig gescannt. Ein Tresor, der auf eine IP-Adresse antwortet, wird gefunden.

Die relevanten Teile eines nginx-Serverblocks:

client_max_body_size 525M;

location / {
  proxy_pass http://127.0.0.1:8000;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection $connection_upgrade;
}

nginx setzt client_max_body_size standardmäßig auf 1 MB. Ohne diese Zeile schlägt der Upload eines Anhangs mit 413 Request Entity Too Large im nginx-Fehlerprotokoll fehl, während Vaultwarden überhaupt nichts protokolliert. Die Header Upgrade und Connection übertragen den WebSocket-Handshake an /notifications/hub. Wenn sie fehlen, funktioniert der Tresor weiterhin. Änderungen werden dann jedoch auf Ihren anderen Geräten nicht mehr angezeigt, bis Sie die Seite manuell neu laden.

Mit Caddy ist die Konfiguration kürzer. Caddy ruft das Zertifikat selbst ab:

vw.example.com {
  reverse_proxy 127.0.0.1:8000 {
    header_up X-Real-IP {remote_host}
  }
}

Teilen Sie Vaultwarden anschließend diese URL mit:

DOMAIN=https://vw.example.com
IP_HEADER=X-Real-IP

IP_HEADER hat bereits den Standardwert X-Real-IP. Sie müssen daher sicherstellen, dass der Proxy diesen Header tatsächlich setzt. Andernfalls sehen jede Protokollzeile und jede Login-Ratenbegrenzung 127.0.0.1, also den Proxy selbst. Dadurch werden die Fehlversuche eines Angreifers allen Benutzern der Instanz zugerechnet. Setzen Sie DOMAIN ebenfalls auf die tatsächliche https-URL. Vaultwarden erstellt daraus Einladungs- und Links zum Zurücksetzen von Passwörtern. Außerdem sind WebAuthn-Sicherheitsschlüssel an diese Origin gebunden.

Ein Detail wird häufig übersehen: Die WebSocket-Verbindung überträgt das Sitzungstoken als /notifications/hub?access_token=[JWT] in der Query-Zeichenfolge. Dadurch landet es unverschlüsselt im Zugriffsprotokoll Ihres Proxys. Redigieren Sie den Parameter access_token im Protokollformat. Alternativ müssen Sie sicherstellen, dass diese Protokolle nicht an einen Ort übertragen werden, den Sie nicht kontrollieren.

Brute-Force-Angriffe am Login-Endpunkt blockieren

Ratenbegrenzungen sind standardmäßig aktiviert (LOGIN_RATELIMIT_SECONDS=60, LOGIN_RATELIMIT_MAX_BURST=10). Sie verlangsamen einen Angreifer. Sie halten ihn jedoch nicht auf. Das übernimmt fail2ban. Vaultwarden muss dafür jedoch zunächst eine Logdatei schreiben. Das geschieht standardmäßig nicht:

LOG_FILE=/data/vaultwarden.log
LOG_LEVEL=info
EXTENDED_LOGGING=true

Ein fehlgeschlagener Login erzeugt dann genau eine Zeile. Nach dieser Zeichenfolge muss Ihr Filter suchen:

[2026-08-07 09:14:22][vaultwarden::api::identity][ERROR] Username or password is incorrect. Try again. IP: 203.0.113.10. Username: user@example.com.

Schreiben Sie den Filter nach /etc/fail2ban/filter.d/vaultwarden.local:

[INCLUDES]
before = common.conf

[Definition]
failregex = ^.*?Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Und den Jail nach /etc/fail2ban/jail.d/vaultwarden.local:

[vaultwarden]
enabled = true
port = 80,443
filter = vaultwarden
banaction = %(banaction_allports)s
logpath = /vw-data/vaultwarden.log
maxretry = 3
bantime = 14400
findtime = 14400

Wenn Sie die Administrationsseite aktiviert haben, fügen Sie einen zweiten Jail hinzu, dessen failregex auf ^.*Invalid admin token\. IP: <ADDR>.*$ gesetzt ist. Fehlgeschlagene Anmeldeversuche im Administrationsbereich werden mit einer anderen Meldung protokolliert. Der Login-Filter erkennt sie daher nicht. Prüfen Sie anschließend Ihre Konfiguration:

sudo systemctl restart fail2ban
sudo fail2ban-client status vaultwarden

Ein funktionierender Jail führt Ihre Logdatei unter File list auf und meldet Currently failed: 0. Geben Sie von einem anderen Netzwerk aus dreimal ein falsches Passwort ein. Der Zähler steigt daraufhin. Anschließend erscheint die Adresse unter Banned IP list. Wenn sich der Zähler nicht ändert, ist logpath meist die Ursache: Es muss der Pfad der Datei auf dem Host sein, nicht der /data/...-Pfad innerhalb des Containers. Die zweithäufigste Ursache ist ein fehlendes X-Real-IP. Dadurch zielt jeder Bann auf Ihren eigenen Proxy. Die übrige Einrichtung, einschließlich des SSH-Jails, den Sie bereits betreiben sollten, wird im fail2ban-Leitfaden für Ubuntu 24.04 beschrieben.

Das Master-Passwort bleibt der zentrale Schutz

Bei clientseitiger Verschlüsselung ist das Master-Passwort der Schlüssel. Ein kurzes Master-Passwort auf einer Instanz, deren Datenbank ein Angreifer kopiert hat, wird durch nichts in diesem Beitrag geschützt, weil der Angreifer diese Kopie offline mit der von seiner Hardware erlaubten Geschwindigkeit angreift. Keine Servereinstellung wirkt auf den eigenen Rechner eines Angreifers.

PASSWORD_ITERATIONS=600000 ist die KDF-Iterationsanzahl, die Clients beim Erstellen eines neuen Kontos erhalten. Bestehende Konten behalten den Wert, mit dem sie erstellt wurden. Eine Erhöhung ändert daher für Benutzer, die sich im letzten Jahr registriert haben, nichts. Sie müssen den Wert selbst in den Sicherheitseinstellungen des Web-Tresors ändern. Dabei wird ihr Schlüssel neu verschlüsselt. Weisen Sie sie darauf hin, denn die Benutzeroberfläche informiert sie darüber nicht.

Aktivieren Sie anschließend die Zwei-Faktor-Authentifizierung für jedes Konto. Sie schützt den Chiffretext nicht, weil der Tresorschlüssel ausschließlich aus dem Master-Passwort abgeleitet wird. Sie verhindert jedoch, dass ein gestohlenes Passwort allein ausreicht, um sich anzumelden und eine Kopie zu synchronisieren. REQUIRE_DEVICE_EMAIL=true fügt beim ersten Anmelden eines Kontos von einem nicht erkannten Gerät eine Bestätigung per E-Mail hinzu.

Backups sind der Punkt, an dem Self-Hosted-Vaults häufig scheitern

Ein tar czf des Datenverzeichnisses, das in einem Home-Verzeichnis auf demselben VPS liegt, macht alle vorherigen Schritte zunichte. Das Archiv enthält db.sqlite3 mit dem Chiffretext aller Benutzer, rsa_key.pem, mit dem sich Anmeldesitzungen fälschen lassen, sowie config.json mit dem Admin-Token und dem SMTP-Passwort im Klartext. Lesezugriff auf diese eine Datei bedeutet Lesezugriff auf den Vault.

Zwei Regeln decken diesen Bereich ab. Übertragen Sie das Archiv vom Server. Verschlüsseln Sie es, bevor es den Server verlässt.

Es gibt außerdem ein Problem mit der Datenkonsistenz. Wenn Sie db.sqlite3 mit cp kopieren, während der Dienst läuft, kann eine Datei entstehen, in die gerade geschrieben wird und die sich nicht öffnen lässt. Das bemerken Sie erst bei der Wiederherstellung. Verwenden Sie stattdessen den Snapshot von SQLite:

sqlite3 /vw-data/db.sqlite3 ".backup '/tmp/vw-db-backup.sqlite3'"

Die Wiederherstellung, die als einzige Hälfte meist niemand testet, wird im Leitfaden zur Sicherung und Wiederherstellung von Vaultwarden behandelt.

Was Sie im Vergleich zu Bitwarden Hosted aufgeben

Ehrliche Einordnung. Der gehostete Dienst von Bitwarden wird von Personen betrieben, deren Vollzeitaufgabe der Betrieb dieses Dienstes ist. Es gibt veröffentlichte Audits durch Dritte und eine Rufbereitschaft rund um die Uhr. Beim Self-Hosting übernehmen Sie stattdessen selbst den Patch-Rhythmus.

Vaultwarden veröffentlicht Sicherheitskorrekturen als reguläre Releases. Version 1.37.0, veröffentlicht am 24. Juli 2026, ist im August 2026 aktuell. In den Release-Hinweisen werden Benutzer aufgefordert, so bald wie möglich zu aktualisieren. Eine Instanz, die Sie vor einem Jahr eingerichtet und danach vergessen haben, läuft mit ein Jahr altem Code. Der latest-Tag hilft allein nicht: Ein laufender Container verwendet weiterhin das Image, mit dem er gestartet wurde, bis Sie docker compose pull ausführen und den Container neu erstellen. Richten Sie unbeaufsichtigte Aktualisierungen auf Ubuntu für die Hostpakete ein. Planen Sie die Aktualisierung des Containers zusätzlich als Kalendereintrag, den Sie tatsächlich lesen.

Die ehrliche Schlussfolgerung lautet: Die Kryptografie basiert hier auf dem Design von Bitwarden und ist belastbar. Das Betriebsrisiko liegt jedoch vollständig bei Ihnen. Wenn Sie die Instanz patchen und die Backups an einem anderen Ort speichern, ist eine Vaultwarden-Instanz auf einem von Ihnen kontrollierten VPS ein sinnvoller Ort für Ihre Passwörter. Wenn diese beiden Gewohnheiten nicht umgesetzt werden, bezahlen Sie für den gehosteten Dienst und verwenden Ihre Aufmerksamkeit für andere Aufgaben. Der Vergleich der einzelnen Funktionen steht unter Vaultwarden im Vergleich mit selbst gehostetem Bitwarden.

Den Host unterhalb des Containers absichern

Vaultwarden ist ein Prozess auf einem Linux-Host. Der Account root auf diesem Host kann /vw-data lesen, unabhängig davon, wie die Anwendung konfiguriert ist. Führen Sie den Container mit einem nicht privilegierten Benutzer aus. Verwenden Sie dazu user: "1000:1000" in Ihrer Compose-Datei und setzen Sie die Eigentümerschaft des Datenverzeichnisses entsprechend. Binden Sie außerdem alles, worin der Container nicht schreibt, mit :ro schreibgeschützt ein. Schließen Sie anschließend den Zugang von außen: SSH auf einem VPS absichern behandelt die Anmeldung ausschließlich mit kryptografischen Schlüsseln und das Deaktivieren der Kennwortauthentifizierung. Dadurch wird der einfache Angriff verhindert, der alle diese Maßnahmen umgehen würde.

FAQ

Kann jemand meine Passwörter lesen, wenn er die Vaultwarden-Datenbank stiehlt?

Nicht direkt. Jedes Tresorelement wird im Client mit einem aus dem Master-Passwort abgeleiteten Schlüssel verschlüsselt. Daher enthält db.sqlite3 Chiffretext. Unmittelbar erhält der Angreifer die E-Mail-Adresse jedes Kontos, die KDF-Einstellungen, Anmelde- und Geräte-Metadaten sowie die Zwei-Faktor-Geheimnisse in der Tabelle twofactor. Diese sind unverschlüsselt gespeichert, weil der Server den erwarteten Code berechnen muss. Außerdem kann der Angreifer den Chiffretext des Tresors beliebig lange offline angreifen. Deshalb entscheidet vor allem die Länge des Master-Passworts über das Ergebnis.

Sollte ich ADMIN_TOKEN verwenden oder die Administrationsseite vollständig deaktivieren?

Deaktivieren Sie sie, wenn möglich. Die meisten Instanzen benötigen sie nur einmal, um SMTP zu konfigurieren und Benutzer einzuladen. Danach wird sie meist nicht mehr benötigt. Setzen Sie zum Deaktivieren weder ADMIN_TOKEN noch DISABLE_ADMIN_TOKEN, entfernen Sie alle "admin_token"-Schlüssel aus config.json und erstellen Sie den Container anschließend neu. Nur die Umgebungsvariable zu entfernen reicht nicht aus, weil die über die Administrationsseite gespeicherten Einstellungen in config.json verbleiben und Vorrang haben. Wenn Sie die Seite aktiviert lassen, speichern Sie das Token als von vaultwarden hash erzeugten Argon2-Hash und nicht als zufällige Zeichenfolge im Klartext. Setzen Sie außerdem ADMIN_RATELIMIT_MAX_BURST=3.

Mein ADMIN_TOKEN ist korrekt, aber /admin weist es zurück. Was ist falsch?

Fast immer liegt die Ursache in der Interpolation von $. Ein Argon2-PHC-String enthält mehrere $-Zeichen. Docker Compose expandiert diese innerhalb eines docker-compose.yml-Blocks environment: als Variablen. Dadurch erhält der Container einen beschädigten Wert, obwohl die Datei korrekt aussieht. Verdoppeln Sie jedes $ in der Compose-Datei zu $$. Alternativ können Sie den Wert in eine .env-Datei verschieben und dort in einfache Anführungszeichen einschließen. Dann ist kein Escaping erforderlich. Erstellen Sie den Container anschließend neu, da Änderungen an der Umgebung durch einen Neustart nicht übernommen werden.

Muss ich Port 3012 für Benachrichtigungen weiterhin öffnen?

Nein. Die Unterstützung für WebSocket-Verkehr auf Port 3012 wurde in Vaultwarden 1.31.0 entfernt, weil Benachrichtigungen auf den zentralen HTTP-Port verlagert wurden. WEBSOCKET_ENABLED und WEBSOCKET_PORT werden seit 1.29.0 ignoriert. Die aktuelle Einstellung lautet ENABLE_WEBSOCKET und ist standardmäßig auf true gesetzt. Schließen Sie Port 3012 in der Firewall und entfernen Sie ihn aus Ihrer Compose-Datei. Stellen Sie anschließend sicher, dass Ihr Reverse Proxy die Header Upgrade und Connection weiterleitet. Davon hängt die Echtzeit-Synchronisierung jetzt tatsächlich ab.