Vaultwarden hosztolása Managed VPS-en: jelszavai a saját szerverén

Mit tud a Vaultwarden

A Vaultwarden egy Rustban írt jelszókezelő szerver, amelyet saját üzemeltetésre terveztek. A wikije magánszemélyeknek, családoknak és emberi léptékű szervezeteknek szánja. A webes széf a Docker image-eivel együtt érkezik.

A hivatalos Bitwarden-kliensekkel kompatibilis API-t valósít meg, a böngészőben, a számítógépen és a telefonon egyaránt. A README leszögezi, hogy a projekt nem áll kapcsolatban a Bitwardennel és a Bitwarden, Inc.-kel, és kéri, hogy bármilyen problémát közvetlenül neki jelezzenek, bármelyik klienst használják is, ne a hivatalos támogatási csatornáknak.

• A széf: személyes széf, csatolmányok, weboldalak ikonjai, személyes API-kulcs, és a Send szöveg vagy fájl továbbítására.
• A szervezetek: gyűjtemények, jelszómegosztás, szerepkörök, csoportok, eseménynaplók és szabályzatok.
• A kétlépcsős hitelesítés: hitelesítő alkalmazás, e-mail, FIDO2 WebAuthn, YubiKey és Duo.
• A mentőövek: vészhozzáférés és fiók-helyreállítás, utóbbihoz be kell állítani az e-mailt.
• Az adminisztráció: egy /admin oldal a beállításokhoz, a fiókokhoz és a diagnosztikához.

A wiki azt is felsorolja, mi hiányzik a hivatalos szerverhez képest, például a hozzáférési kulccsal (passkey) való bejelentkezés, az egyéni szerepkörök és néhány vállalati szabályzat. Hozzáteszi, hogy a főként nagy szervezeteknek hasznos funkciók nem élveznek elsőbbséget a projektben: olvassa el ezt a listát, ha szüksége van rájuk.

Mit enged meg az AGPL-3.0 licenc

A Vaultwarden a GNU Affero General Public License, 3. verzió alatt jelenik meg. A szöveg korlátlan engedélyt ad a módosítatlan program futtatására. A projekt által közzétett image-et tehát használhatja a vállalkozásához és a csapatához, licenc vásárlása nélkül.

A 13. szakasz az AGPL-re jellemző feltételt tesz hozzá: ha módosítja a programot, a változatának mindenkinek, aki távolról, a hálózaton keresztül használja, lehetőséget kell adnia a forráskód ingyenes megszerzésére.

Telepítés Docker Compose-zal

A README a konténer-image-eket ajánlja. Egy olyan szerveren, ahol a Docker telepítve van, hozzon létre egy mappát, és helyezze bele ezt a compose.yaml fájlt, amely a README-ből és a wikiből származik:

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80

docker compose up -d

• A 127.0.0.1 címen közzétett port: ahogyan a README-ben, a Vaultwarden csak az ugyanazon a szerveren lévő fordított proxyn keresztül érhető el.
• A DOMAIN: a példánya alapcíme, https előtaggal. A wiki figyelmeztet, hogy enélkül egyes funkciók elromlanak, köztük a csatolmányok és a meghívó linkek.
• Egy vw-data mappa helyi lemezen: ez őriz minden adatot. A wiki jelzi az SQLite gondjait CIFS vagy Samba kötetén, amely nem kezeli a zárolást.
• A latest címke a legutóbb közzétett verziót követi, és a wiki a legtöbb felhasználásra ezt ajánlja. Egy olyan címke, mint az 1.37.5, rögzít egy verziót, a latest-alpine pedig ugyanezt adja Alpine alapon.

A domainnévnek A és AAAA rekordokkal a szerverre kell mutatnia, a látogatók pedig a 80-as és a 443-as porton érkeznek. Amíg a fordított proxy nincs a helyén, a webes széf használhatatlan: lépjen egyenesen a következő szakaszra.

A projekt nem ad meg memória- és processzorigényt; csak olyan megoldásként mutatkozik be, amelyet akkor érdemes választani, ha a hivatalos, erőforrás-igényes szolgáltatás nem megfelelő. A méret a fiókok számától és a csatolmányok mennyiségétől függ. Egy Managed VPS esetén írja le nekünk a használatát, és mi azt a méretet javasoljuk, amely megfelel.

HTTPS és WebSocket: a fordított proxy

A webes széf a Web Crypto API-ra épül, amelyet a böngészők csak biztonságos környezetnek tartanak fenn: a README szerint csak bekapcsolt HTTPS mellett működik, a wiki pedig a HTTPS-t „pretty much required”-nek, vagyis szinte kötelezőnek tartja. A projekt fordított proxyt javasol a Vaultwarden elé, és nem ajánlja a Rocket keretrendszerébe épített TLS-t.

Használjon elismert tanúsítványt, például a Let's Encryptét, amelyet a wiki ajánl: önaláírt tanúsítvánnyal egyes platformok megtagadják a kapcsolatot. A tanúsítványnak a teljes láncot tartalmaznia kell, különben az Android-eszközök nem tudnak csatlakozni.

A WebSocket-értesítések, amelyek alapértelmezésként aktívak, jelzik a böngészőnek, az asztali alkalmazásnak és a bővítménynek, hogy egy bejegyzés megváltozott. A fő HTTP-porton haladnak át, és a proxynak át kell adnia az Upgrade és a Connection fejlécet. A mobilalkalmazások a rendszerük natív értesítéseit használják, amelyeket külön kell beállítani.

Caddyvel

A wiki azt tanácsolja, hogy ha nincs preferenciája, először a Caddyt nézze meg: magától bekapcsolja a HTTPS-t, megszerzi a Let's Encrypt-tanúsítványt, és kezeli a WebSocketet. A wiki beállítása a látogató valódi címét is továbbítja a Vaultwardennek, a naplóihoz:

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

Nginxszel és Certbottal

Ez a blokk a wiki Nginx-példáját veszi át, a 80-as portra szűkítve, hogy a Certbot állíthassa be a HTTPS-t:

upstream vaultwarden-default {
  zone vaultwarden-default 64k;
  server 127.0.0.1:8000;
  keepalive 2;
}

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      "";
}

server {
    listen 80;
    listen [::]:80;
    server_name vault.example.com;

    client_max_body_size 525M;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    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;

    location / {
      proxy_pass http://vaultwarden-default;
    }
}

A Certbot ezután telepíti a tanúsítványt, és gondoskodik a megújításáról:

sudo certbot --nginx

A WebSocket ellenőrzése

Nyissa meg a böngésző fejlesztői eszközeit, a hálózat lapot, a WS szűrőt, majd jelentkezzen be újra a széfbe: a /notifications/hub címen kapott 101-es válasz igazolja a kapcsolatot. A wiki másik tesztje: nyissa meg a széfet két böngészőben, nevezzen át egy bejegyzést az egyikben, és a változás azonnal megjelenik a másikban.

A regisztrációk lezárása

Alapértelmezésként bárki létrehozhat fiókot, aki eléri a példányát. Ez hasznos az első fiókhoz, a wiki pedig azt ajánlja, hogy utána zárja le, hogy egy támadó ne tudjon újat létrehozni.

1. Nyissa meg a HTTPS-címét, hozza létre a fiókját, majd kösse hozzá az alkalmazásait ehhez a címhez.
2. Állítsa a SIGNUPS_ALLOWED értékét "false"-ra a compose.yaml fájlban.
3. Indítsa újra a docker compose up -d paranccsal: a környezeti változó a konténerhez kötődik, amelyet újra kell létrehozni, hogy érvénybe lépjen.

SIGNUPS_ALLOWED: "false"

• A meghívások nyitva maradnak a lezárás után is: egy szervezet tulajdonosai és adminisztrátorai új személyeket hívhatnak meg. Az INVITATIONS_ALLOWED "false" értéke megszünteti ezt a lehetőséget, a wiki pedig a felhasználóiba vetett bizalmára bízza a döntést.
• Egy domainlista: a SIGNUPS_DOMAINS_WHITELIST bizonyos e-mail-domainekre korlátozza a regisztrációt, a SIGNUPS_VERIFY true értéke pedig ekkor előírja a cím ellenőrzését. Ha ez a lista be van állítva, a SIGNUPS_ALLOWED figyelmen kívül marad.
• Az adminisztrációs oldal ezektől a korlátozásoktól függetlenül bárkit meghívhat.

Amint az adminisztrációs oldalról elmenti a konfigurációt, egy config.json fájl jön létre az adatmappában, amely felülírja a környezeti változókat. Az érintett beállítások ezután erről az oldalról módosíthatók: a compose.yaml módosítása már nem elég.

Az adminisztrációs oldal és tokenje

A /admin oldal a Vaultwarden beállítására, a fiókok és a szervezetek megtekintésére és törlésére, egy felhasználó kétlépcsős hitelesítésének eltávolítására, meghívásra és a diagnosztika olvasására szolgál. ADMIN_TOKEN nélkül letiltva marad: ha nincs rá szüksége, hagyja így.

A wiki határozottan azt ajánlja, hogy kapcsolja be a HTTPS-t, mielőtt ezt az oldalt használja. A token jelszóként szolgál, és a konfigurációban egyszerű szöveg helyett argon2id-vel képzett hash formájában is tárolható. A Vaultwarden megadja ehhez a parancsot: kétszer kéri a jelszót, majd egy PHC-karakterláncot ad vissza.

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

Helyezze ezt a karakterláncot egy .env fájlba, a compose.yaml mellé, aposztrófok közé, majd hivatkozzon rá a szolgáltatásból:

VAULTWARDEN_ADMIN_TOKEN='$argon2id$...'

ADMIN_TOKEN: ${VAULTWARDEN_ADMIN_TOKEN}

Ellenőrizze az eredményt, indítsa újra, majd jelentkezzen be a /admin címen a jelszavával, nem pedig a PHC-karakterlánccal:

docker compose config
docker compose up -d

• A munkamenet alapértelmezésként 20 percig tart, az ADMIN_SESSION_LIFETIME változóval állítható. Egy megnyitott munkamenet a token cseréje után is érvényes marad. Az összes megszakításához törölje a rsa_key.pem fájlt az adatmappából, és indítsa újra a szolgáltatást, ami a felhasználókat is kijelentkezteti, és érvényteleníti a folyamatban lévő meghívókat.
• Szűkített hozzáférés: a wiki proxypéldái megmutatják, hogyan nyissa meg a /admin oldalt csak bizonyos címeknek, vagy hogyan adjon hozzá HTTP-hitelesítést.
• A DISABLE_ADMIN_TOKEN minden ellenőrzést megszüntet: egy elé helyezett, különálló hitelesítési réteghez készült, a wiki pedig azoknak tartja fenn, akik tudják, mit csinálnak.

Ami a széfet védi

Az első védelem a mesterjelszó. A széf adatai személyes vagy szervezeti kulcsokkal vannak titkosítva: aki megszerzi az adatbázis egy másolatát, vagy erőszakkal belép egy munkamenetbe, annak még fel kell törnie ezt a jelszót, hogy elolvashassa őket. Az erőssége tehát mindenekelőtt számít. Maga egy adminisztrációs munkamenet lehetővé teszi egy fiók törlését vagy egy kétlépcsős hitelesítés eltávolítását, de nem ad hozzáférést a széf adataihoz.

Készüljön fel a mesterjelszó elfelejtésére, mielőtt megtörténne: kapcsolja be a fiókja vészhozzáférését, egy szervezetben pedig a fiók-helyreállítást, amelyhez beállított e-mail kell.

Három további beállítás a megerősítési útmutatóból

• Nem root fiók: az image alapértelmezésként root-ként fut, a wiki pedig jobbnak tartja, ha a lehető legkevesebb jogot kapja. Adja hozzá a user: 1000:1000 sort a szolgáltatáshoz, olyan vw-data mappával, amely ehhez a felhasználóhoz tartozik.
• A proxy naplói: a WebSocket-kapcsolat egy tokent ad át a címben, access_token néven. Ha a proxyja megőrzi a naplóit, vagy külső szolgáltatásnak küldi őket, a wiki azt ajánlja, hogy rejtse el ezt az értéket.
• A lehető legkevesebb csatolás: az adatmappát csatolja, és semmi mást, sem a személyes mappáját, sem a /var/run/docker.sock fájlt.

SQLite, MariaDB vagy PostgreSQL

Ugyanaz az image mind a három adatbázist támogatja. A wiki az SQLite-ot a legelterjedtebbként és a legtöbbet tesztelt adatbázisként írja le, és a legtöbb felhasználásra ezt ajánlja, kivéve, ha kifejezetten másikra van szükség.

DATABASE_URL: "postgresql://user_name:user_password@db_host:5432/vaultwarden"

Hozzon létre egy üres adatbázist és a hozzá tartozó felhasználót: induláskor a Vaultwarden maga hozza létre benne a sémáját. A speciális karaktereket tartalmazó jelszót százalékkódolással kell írni ebben a címben.

Ezt a választást a széf feltöltése előtt tegye meg. A wiki leír egy SQLite-ról PostgreSQL-re való áttérést a pgloader segítségével, megjegyezve, hogy a projekt ezt az utat nem támogatja, saját felelősségre történik, és mentéssel kezdődik.

Az e-mailek: az SMTP-konfiguráció

A Vaultwarden e-mail nélkül indul, de több funkció ettől függ: a meghívók, a címek ellenőrzése, a jelszó-emlékeztetők küldése, az e-mailes kétlépcsős hitelesítés és a fiók-helyreállítás.

Simafri VPS-en a küldés egy hitelesített SMTP-továbbítón keresztül megy, a 587-es porton: egy meglévő levelezési fiók címével, vagy a Simafri Suite-tal. A jelszót az .env fájlba helyezze, mint az adminisztrációs tokent:

SMTP_HOST: "smtp.example.com"
SMTP_FROM: "vault@example.com"
SMTP_PORT: "587"
SMTP_SECURITY: "starttls"
SMTP_USERNAME: "vault@example.com"
SMTP_PASSWORD: ${VAULTWARDEN_SMTP_PASSWORD}

• A meghívó linkek a DOMAIN alapján épülnek fel, és 5 napig érvényesek.
• Microsoft: a wiki jelzi, hogy a Hotmail, az Outlook és az Office 365 immár OAuth2-t kér, amelyet a Vaultwarden még nem támogat. A felismerendő hiba: No compatible authentication mechanism was found.
• Gmail: a wiki szerint számítson egy alkalmazásjelszóra.
• A próba: az adminisztrációs oldal tesztüzenetet küld. Ha ott módosít egy SMTP-beállítást, előbb mentse el, mert a teszt a mentett beállításokat használja, és ez a mentés hozza létre a config.json fájlt.

Ha semmi sem indul el, a wiki azt javasolja, hogy tesztelje a továbbítóhoz való kapcsolódást a szerverről. A parancs 0-t ad vissza, ha a továbbító válaszol:

timeout 5 bash -c 'cat < /dev/null > /dev/tcp/smtp.example.com/587'; echo $?

A mentések

A README emlékeztet rá, hogy a projekt nem tehető felelőssé adatvesztésért, és határozottan rendszeres mentéseket ajánl. A wiki automatikusat tanácsol, legalább egy másolattal máshol. Íme, mit tartalmaz az adatmappa SQLite esetén:

Az adatbázis, futó szolgáltatás mellett

Az 1.32.1-es verziótól a Vaultwarden képes maga lementeni az SQLite-adatbázisát, a szolgáltatás leállítása nélkül:

docker exec -it vaultwarden /vaultwarden backup

A parancs egy db_AAAAMMJJ_HHMMSS.sqlite3 fájlt ír az adatbázis mellé, a vw-data mappába. Az image nem tartalmaz sem sqlite3-at, sem cron-t: a wiki azt tanácsolja, hogy ütemezze a feladatot a szerveren, legalább naponta egyszer. Ilyenkor hagyja el a -it kapcsolót, mert egy ütemezett feladatnak nincs terminálja, és válogassa ki ezeket a fájlokat, mert felhalmozódnak.

A teljes mappa, leállított szolgáltatás mellett

Ha az adatbázist nem használják, elég az összes fájljának egyszerű másolata. Ez az a leállított szolgáltatással végzett módszer, amelyet a wiki a Dockerhez példaként ad, és a csatolmányokat is magával viszi:

docker compose down
tar -czf vaultwarden-$(date +%F).tar.gz vw-data
docker compose up -d

A wiki hasznosnak tart egy titkosítási réteget, különösen ha a mentés tartalmazza az adminisztrációs tokent és az SMTP-hozzáféréseket, és az rclone, a restic és a rustic eszközt említi a másolatok távoli küldéséhez. MariaDB vagy PostgreSQL esetén adjon az adatbázis exportját a vw-data mappához.

A wiki azt kéri, hogy ne bízza magát kizárólag a lemezpillanatképekre, amelyeket nehezebb visszaállítani. Őrizze tehát ezeket az alkalmazás saját másolatait: a szerver lemezére téve a szerver éjszakai mentéseibe is bekerülnek.

Visszaállítás

1. Állítsa le a Vaultwardent.
2. Cserélje le a vw-data minden fájlját vagy mappáját a mentett változatára.
3. Ha az adatbázis a /vaultwarden backup parancsból származik, nevezze át db.sqlite3-ra, és előbb törölje a meglévő db.sqlite3-wal fájlt: egy nem hozzá tartozó napló megsérthet az adatbázist. Ha közvetlen másolatból származik, állítsa vissza együtt a db.sqlite3 és a hozzá tartozó db.sqlite3-wal fájlt.
4. Indítsa újra, majd ellenőrizze, hogy meg tudja-e nyitni a széfet.

A wiki azt tanácsolja, hogy ezt a gyakorlatot időnként ismételje meg, az adatok egy másolatát a helyén tartva: így győződhet meg róla, hogy egy mentés működik.

A frissítések

A wiki két parancsot ad meg, a compose.yaml mappájából. Az adatmappa a helyén marad:

docker compose pull
docker compose up -d

Ezek a frissítések másutt nem látott súllyal bírnak. A mobilalkalmazások és a böngészőbővítmények maguktól frissülnek, és a wiki figyelmeztet, hogy a szerverrel való verzióeltérés hirtelen hibákat okozhat. A webes széf, amely az image-ben érkezik, mindig összhangban marad a szerverével.

A projektnek nincs kiadási naptára: kövesse a kiadási megjegyzéseit, és minden frissítés előtt közvetlenül készítsen mentést. Némelyik biztonsági javításokat tartalmaz, mint a 2026. november 1-jei 1.37.5-ös, amelynek megjegyzései a lehető leghamarabbi frissítést javasolják. Ezek a megjegyzések arra is figyelmeztetnek, hogy az 1.37.5-ös verziótól egy érvénytelen konfigurációs érték megakadályozza a Vaultwarden indulását: frissítés előtt nézze át újra a környezeti fájlját. A /admin diagnosztikai oldala jelzi, ha létezik újabb verzió.

Ki mit csinál egy Managed VPS-en

A saját üzemeltetés az alkalmazás mellett a szerver gondozását is megköveteli. Egy Managed VPS esetén csapataink átveszik a szervert, és proaktívan követik a példányát; a Vaultwarden továbbra is az Ön szoftvere marad, a beállításaival és az adataival.

Ha inkább azt szeretné, hogy csapataink magában az alkalmazásban avatkozzanak be, ez a szolgáltatás óradíjban vagy átalánydíjban számlázódik, a beavatkozás előtt közölt árajánlattal.