Від Matt Connor 2026-10-11

Vaultwarden на VPS: як розгорнути свій менеджер паролів

Q: Як заборонити стороннім користувачам реєструватися на моєму сервері?

Установіть SIGNUPS_ALLOWED: "false" у Compose-файлі та виконайте docker compose up -d одразу після створення власного облікового запису. Після цього додавайте нових користувачів за допомогою кнопки Invite User у /admin. Для цього потрібно налаштувати SMTP, щоб вони отримували посилання для запрошення. Періодично перевіряйте список користувачів адміністратора, щоб виявити неочікувані облікові записи.

Q: Як створити резервну копію сховища Vaultwarden?

Ненадовго зупиніть контейнер і заархівуйте весь том vw-data, db.sqlite3, attachments/, sends/, config.json і файли rsa_key.*. Потім скопіюйте архів із сервера, бажано за допомогою нічного cron. Копіювання активного файла SQLite під час роботи сервера може призвести до пошкодженого знімка, тому створюйте резервну копію після зупинки сервера. Найважливіше — один раз відновити її в тимчасовому контейнері та виконати вхід, щоб перевірити резервну копію до того, як почнете на неї покладатися.

Розгорніть сумісний із Bitwarden менеджер паролів через Docker на VPS: HTTPS до першого входу, admin token, Fail2ban і перевірені резервні копії.

Що ви створюєте

Повністю ваш менеджер паролів: Vaultwarden працює в одному невеликому контейнері за reverse proxy, який завершує HTTPS, а офіційні застосунки Bitwarden на телефоні, ноутбуці та в браузері підключені до нього. Vaultwarden повторно реалізує API сервера Bitwarden мовою Rust і використовує той самий протокол, що й bitwarden.com. Тому офіційні клієнти працюють із ним без змін, якщо сервер залишається актуальним. Нові версії клієнтів іноді потребують відповідної версії Vaultwarden: для клієнтів 2026.8.0 і новіших потрібна версія 1.37.2. Водночас Vaultwarden використовує приблизно 100 MB RAM замість офіційного стеку з кількох контейнерів.

Сама інсталяція складається з десятка рядків Compose. Критично важливі саме три речі, через які найчастіше виникають проблеми: TLS має бути налаштований до першого відкриття вебсховища, публічну реєстрацію потрібно закрити одразу після створення власного облікового запису, а том із даними потрібно резервно копіювати та перевіряти відновленням. Саме в цьому каталозі зберігаються всі ваші паролі.

Передумови та важливі обмеження

VPS із Docker Engine і плагіном Compose на чистому Ubuntu 24.04 у KVM із root або sudo. 512 MB RAM справді достатньо; 1 GB забезпечує комфортний запас. Це один із найлегших сервісів для запуску, він посідає чільне місце в короткому списку сервісів, які варто розгортати самостійно. Однак розраховуйте розмір VPS з урахуванням інших сервісів: розміщення self-hosted фототеки на кшталт PhotoPrism або Immich на тому самому VPS підвищує мінімальну потребу в RAM до кількох гігабайтів, тоді як Vaultwarden майже не збільшує її. Такий самий розрахунок стосується медіафронтендів, які ви додасте пізніше, оскільки перетворення бібліотеки Jellyfin на інтерактивний відеопрокат у стилі 90-х означає ще один постійно запущений контейнер і додатковий запас ресурсів для транскодування в межах того самого бюджету.
Домен із записом A (і AAAA, якщо у вас є IPv6), що вказує vault.example.com на VPS. TLS-сертифікат видається для цього конкретного імені, тому DNS має повертати потрібну адресу до початку налаштування.
Порти 80 і 443, відкриті для інтернету та оброблювані reverse proxy, ніколи не самим Vaultwarden. Порт 80 використовується лише для ACME-перевірки сертифіката та перенаправлення HTTP на HTTPS.
Найважливіше обмеження: клієнти Bitwarden відмовляються підключатися до сервера без HTTPS. Варіант «спочатку перевірити через http» не працює. Причину цього пояснено в наступному розділі.

Чому Vaultwarden, а не офіційний стек Bitwarden

Ті самі клієнти за значно менших вимог до ресурсів. Стандартне офіційне self-hosted розгортання Bitwarden складається з набору контейнерів (MSSQL Express, Identity, Api, Admin та інших) і потребує щонайменше 2 GB RAM. Bitwarden також пропонує Bitwarden lite — один Docker image, якому потрібно щонайменше 200 MB RAM. Проте він призначений для особистого використання та home lab, а не для бізнесу, і повністю залишає базу даних та її резервні копії під вашою відповідальністю. Vaultwarden — це один binary, який за замовчуванням зберігає всі дані в SQLite database і в режимі простою використовує лише кілька десятків мегабайт. Для однієї людини, сім’ї або невеликої команди це очевидний вибір. Оскільки Vaultwarden коректно реалізує Bitwarden API, ваші дані залишаються переносними між ним і bitwarden.com.

Ви відмовляєтеся від більшої частини enterprise-функцій: SCIM provisioning відсутній, хоча підтримку OpenID Connect SSO додали у 1.35.0. Крім того, оператором є ви, тому патчі, HTTPS і резервне копіювання — ваша відповідальність. Цей посібник присвячений саме цим трьом завданням.

Чому HTTPS є обов’язковим

Вебсховище Bitwarden і розширення для браузерів отримують ключі шифрування у браузері за допомогою Web Crypto API (window.crypto.subtle). Браузери надають crypto.subtle лише в безпечному контексті — через HTTPS або у спеціальному випадку для loopback-адрес, таких як http://localhost і http://127.0.0.1. Через звичайний http://vault.example.com це undefined, тому під час отримання ключа застосунок одразу видає помилку, а консоль показує:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'importKey')

Сторінка зависає або показує загальну помилку криптографії, а вхід не виконується. Настільні, мобільні клієнти та клієнти для браузерів самостійно перевіряють self-hosted URL. Для http- або недоступної кінцевої точки вони відмовляють із повідомленням:

This is not a recognized Bitwarden server. You may need to check with your provider or update your server.

Причина в обох випадках одна: немає дійсного HTTPS. Тому спочатку налаштовуємо TLS і ніколи не відкриваємо сховище через http, навіть один раз для швидкої перевірки.

Крок 1. DNS і reverse proxy (спочатку TLS)

Спрямуйте запис на свій VPS і переконайтеся, що він розв’язується в правильну адресу:

dig +short vault.example.com

Виведений рядок має містити IP-адресу вашого VPS. Якщо рядок порожній або містить неправильну адресу, виправте DNS і дочекайтеся завершення TTL. Інакше випуск сертифіката завершиться помилкою, оскільки ім’я не розв’язується.

Для HTTPS front end у цьому посібнику використовується Traefik. Він автоматично випускає та поновлює сертифікати Let's Encrypt і безпосередньо інтегрується з Compose. Якщо ви ще не використовуєте його, спочатку виконайте налаштування reverse proxy Traefik та автоматичного TLS. Воно створює зовнішню Docker network (proxy нижче) і ACME resolver (letsencrypt), до якого підключається сервіс Vaultwarden. Звичайний nginx із сертифікатом, випущеним вручну, працює для Vaultwarden так само.

Віддаєте перевагу nginx і Certbot замість Traefik? Підключіть Vaultwarden до 127.0.0.1:8080 (додайте ports: ["127.0.0.1:8080:80"] до сервісу та видаліть labels Traefik), потім випустіть сертифікат і налаштуйте proxy до цього сервісу. Випуск сертифіката описано в розділі випуск сертифікатів Let's Encrypt за допомогою Certbot і nginx. Критично важливо додатково налаштувати WebSocket upgrade для notifications path:

server {
    listen 443 ssl;
    server_name vault.example.com;

    client_max_body_size 525M;

    location / {
        proxy_pass http://127.0.0.1:8080;
        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_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Зверніть увагу на рядок X-Real-IP. Саме він дає змогу Fail2ban надалі бачити реальну IP-адресу зловмисника, а не 127.0.0.1. Усе інше в цьому посібнику однакове незалежно від того, Traefik чи nginx працює перед сервісом.

Крок 2, файл Compose

Спочатку створіть каталог проєкту. У цьому посібнику використовується /opt/vaultwarden. Завдяки цьому ім’я проєкту Compose і, відповідно, том даних vaultwarden_vw-data залишаються передбачуваними. Наведені нижче кроки для Fail2ban і резервного копіювання залежать від цього точного імені.

sudo mkdir -p /opt/vaultwarden
cd /opt/vaultwarden

Створіть у цьому каталозі .env для секрету адміністратора та файл Compose.

# .env
ADMIN_TOKEN=paste-a-strong-token-here

Згенеруйте цей токен за допомогою openssl rand -base64 48 і вставте його у файл. Наступний розділ описує надійнішу хешовану форму; для початку достатньо довгого випадкового рядка.

# docker-compose.yml
services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vault.example.com"
      SIGNUPS_ALLOWED: "true"          # closed in Step 4, keep true just to register
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      IP_HEADER: "X-Forwarded-For"     # X-Real-IP if your proxy sends that instead
      LOG_FILE: "/data/vaultwarden.log"
      LOG_LEVEL: "warn"
    volumes:
      - vw-data:/data
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vw.rule=Host(`vault.example.com`)"
      - "traefik.http.routers.vw.entrypoints=websecure"
      - "traefik.http.routers.vw.tls.certresolver=letsencrypt"
      - "traefik.http.services.vw.loadbalancer.server.port=80"

volumes:
  vw-data:

networks:
  proxy:
    external: true

Цей файл містить два ключові елементи всієї схеми. Тут немає зіставлення ports:, тому Vaultwarden доступний лише через Traefik і його TLS. Публікація порту Vaultwarden на хості призводить до того, що сховище випадково стає доступним через http. Крім того, DOMAIN має бути повною публічною HTTPS-URL-адресою. Вона вбудовується в посилання на вкладення, 2FA WebAuthn і endpoint сповіщень. Тому неправильне значення або значення з http порушить їхню роботу, навіть якщо сайт завантажується. Тег latest є свідомим винятком із загального правила ніколи не використовувати latest. Vaultwarden випускає стабільні версії як один rolling image, а :testing є окремим каналом попередніх версій. Тому оновлюйте його навмисно та переглядайте release notes перед завантаженням образу. Виняток має вузьке застосування. Більшість довгоживучих контейнерів краще прив’язувати до точного тегу. Саме це забезпечує передбачувану роботу постійно активного self-hosted агента на тому самому VPS після перезавантажень і повторного завантаження образів.

Запустіть стек і стежте за журналом:

docker compose up -d
docker compose logs -f vaultwarden

Коректний запуск завершується рядком на кшталт Rocket has launched from http://0.0.0.0:80. Зачекайте кілька секунд, поки Traefik отримає сертифікат, а потім відкрийте https://vault.example.com. Ви маєте побачити вебсховище Bitwarden із дійсним сертифікатом і без попередження про сертифікат.

Крок 3: надійний ADMIN_TOKEN і пастка з $$

ADMIN_TOKEN захищає /admin — панель, яка може читати дані кожного користувача та всі налаштування вашого екземпляра. Тому поводьтеся з ним як із паролем root. Працюють два варіанти.

Простий варіант — випадковий рядок, який ви вже згенерували за допомогою openssl rand -base64 48. Оскільки base64 ніколи не містить $, його можна безпосередньо вставити в .env без екранування.

Захищений варіант — хеш Argon2 PHC. У такому разі токен у відкритому вигляді не зберігається на диску. Згенеруйте його на основі того самого образу:

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

Команда двічі запитує токен і виводить рядок, що починається з $argon2id$v=19$.... Тут є пастка, яка може забрати годину: Docker Compose сприймає $ як інтерполяцію змінних. Тому, якщо вставити хеш безпосередньо під environment: у Compose-файлі, потрібно подвоїти кожен $ до $$. Значення можна взяти в лапки; важливе саме екранування:

    environment:
      ADMIN_TOKEN: $$argon2id$$v=19$$m=19456,t=2,p=1$$c29tZXNhbHQ$$RdescudvJCsgt3ub+b+dWRWJTmaaJObG

Якщо ви хочете зберігати хеш у .env, правило змінюється: залиште одиночні знаки $, візьміть усе значення в одинарні лапки (ADMIN_TOKEN='$argon2id$v=19$...'), і наявний рядок ${ADMIN_TOKEN} у Compose-файлі використає це значення. Ніколи не подвоюйте $ у .env. Якщо залишити одиночні знаки $ безпосередньо в Compose-файлі, Compose попередить про The "argon2id" variable is not set і очистить токен, після чого /admin відхилить навіть правильний пароль. Виконайте docker compose up -d і збережіть введений у запиті токен у власному менеджері паролів.

Крок 4. Зареєструйте обліковий запис і закрийте доступ до реєстрації

За допомогою SIGNUPS_ALLOWED: "true" відкрийте https://vault.example.com, натисніть Create account і зареєструйтеся за допомогою своєї електронної адреси та надійного master password. Відновити цей master password неможливо. Скидання не передбачено, тому спочатку збережіть його в надійному місці.

Тепер вимкніть реєстрацію. Відредагуйте Compose-файл:

      SIGNUPS_ALLOWED: "false"

Повторно застосуйте зміни за допомогою docker compose up -d. Це налаштування безпеки не можна відкладати. Якщо реєстрацію залишити відкритою, будь-хто, хто знайде URL, зокрема crawler, зможе створити обліковий запис на вашому сервері. Ці користувачі не зможуть прочитати ваше сховище, але споживатимуть ресурси та перетворять ваш приватний інстанс на загальнодоступний сервіс. Ознака того, що реєстрацію не вимкнено: /admin містить облікові записи, які ви не створювали.

Щоб пізніше додати членів сім’ї або колег без повторного відкриття загальнодоступної реєстрації, скористайтеся кнопкою Invite User у /admin. Для цього потрібно налаштувати SMTP, щоб запрошений користувач отримав посилання.

Крок 5. Перехід до /admin

Відкрийте https://vault.example.com/admin і введіть незашифрований токен адміністратора (випадковий рядок або пароль, для якого ви обчислили хеш, а не сам хеш). У панелі можна переглядати список користувачів, змінювати параметри, надсилати тестовий email і створювати знімок бази даних.

Якщо натомість сторінка показує The admin panel is disabled, please configure the 'ADMIN_TOKEN' variable to enable it, параметр ADMIN_TOKEN порожній або не заданий. Це повністю вимикає панель і може бути правильним вибором, якщо вона вам не потрібна. Якщо панель відкривається, але відхиляє ваш токен, див. проблему з екрануванням $$ у наведеному нижче списку помилок. Забули токен? Функції відновлення немає. Відредагуйте .env або Compose-файл, задайте новий токен і docker compose up -d.

Крок 6. Підключіть клієнти Bitwarden

Кожен офіційний клієнт може підключатися до self-hosted сервера. Встановіть клієнт Bitwarden для desktop, mobile або browser зі звичайного магазину. Спеціальна збірка Vaultwarden не потрібна.

Перед входом відкрийте меню налаштувань на екрані входу (пункт Self-hosted або Region → Self-hosted), у полі Server URL вкажіть https://vault.example.com і збережіть зміни. Потім увійдіть за допомогою зареєстрованої email-адреси та master password. Клієнт має одразу підключитися й запропонувати заповнювати та зберігати облікові дані.

Якщо клієнт показує This is not a recognized Bitwarden server. You may need to check with your provider or update your server., URL неправильний, використовується http або сертифікат не вважається довіреним. Спочатку перевірте в браузері, що https://vault.example.com відкривається без помилок. Повільне оновлення на інших пристроях пов’язане з WebSocket push; це описано нижче.

Крок 7: jail Fail2ban для endpoint входу

Vaultwarden записує кожну невдалу спробу входу у файл, заданий через LOG_FILE. Це саме ті дані, які потрібні для захисту від brute-force-атак. Якщо Fail2ban ще не запущено, інструкції зі встановлення та базового налаштування наведено в посібнику із захисту SSH за допомогою Fail2ban. Тут ми додамо один jail для vault.

Спочатку знайдіть, де на хості розташований named volume, щоб Fail2ban міг читати журнал:

docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}'

Команда виведе щось на кшталт /var/lib/docker/volumes/vaultwarden_vw-data/_data. Журнал розташований у vaultwarden.log всередині цього тому. Створіть filter:

# /etc/fail2ban/filter.d/vaultwarden.conf
[Definition]
failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$
ignoreregex =

Потім створіть jail:

# /etc/fail2ban/jail.d/vaultwarden.local
[vaultwarden]
enabled   = true
filter    = vaultwarden
logpath   = /var/lib/docker/volumes/vaultwarden_vw-data/_data/vaultwarden.log
banaction = iptables-allports
chain     = DOCKER-USER
maxretry  = 5
findtime  = 600
bantime   = 3600

Перезавантажте конфігурацію за допомогою sudo systemctl restart fail2ban і перевірте результат командою sudo fail2ban-client status vaultwarden.

Є три деталі Docker, від яких залежить, чи забезпечуватиме це налаштування захист. По-перше, якщо журнал містить IP: 127.0.0.1 або адресу вашого proxy під час кожної невдалої спроби, Vaultwarden блокуватиме proxy. Установіть IP_HEADER у заголовок, який насправді надсилає ваш proxy: X-Forwarded-For для Traefik, X-Real-IP для наведеного вище блоку nginx і CF-Connecting-IP у разі використання Cloudflare. Починаючи з версії 1.37.4, з параметром X-Forwarded-For Vaultwarden використовує крайню праворуч адресу, якої немає в IP_HEADER_TRUSTED_PROXIES. Типове значення local охоплює proxy на тому самому хості або в тій самій Docker network. Тому якщо перед вашим proxy розташований CDN, додайте його адреси також.

По-друге, потрібний ланцюжок iptables залежить від вашого proxy. Якщо Traefik працює як контейнер з опублікованими портами, трафік проходить через шлях Docker FORWARD. Тому блокування має застосовуватися в DOCKER-USER, як показано вище. Якщо на Кроці 1 ви вибрали варіант із host-nginx, з’єднання завершуються в nginx на хості через ланцюжок INPUT. Блокування DOCKER-USER їх не побачить. У такому разі видаліть рядок chain = DOCKER-USER, щоб Fail2ban використовував типовий ланцюжок INPUT.

По-третє, використовуйте banaction = iptables-allports замість типового значення на основі портів. Цей jail не визначає порт, а блокування всіх портів у DOCKER-USER коректно забороняє порушнику доступ до кожного опублікованого сервісу на цьому хості.

Крок 8. Створіть резервну копію сховища, а потім фактично відновіть її

Том vw-data є вашим менеджером паролів. У ньому зберігаються db.sqlite3 (кожен запис), каталоги attachments/ і sends/, файли rsa_key.*, якими підписуються сеанси входу, а також config.json з адміністративної панелі. Резервна копія, у якій бракує будь-якого з цих компонентів, не допоможе під час відновлення.

Копіювання db.sqlite3 під час запису Vaultwarden може зберегти незавершений і пошкоджений файл, тому створюйте холодний знімок. Простій триватиме кілька секунд:

#!/usr/bin/env bash
set -euo pipefail
STAMP=$(date +%F)
DEST=/root/vw-backups
VOL=$(docker volume inspect vaultwarden_vw-data --format '{{ .Mountpoint }}')
mkdir -p "$DEST"
docker compose -f /opt/vaultwarden/docker-compose.yml stop vaultwarden
tar czf "$DEST/vw-$STAMP.tgz" -C "$VOL" .
docker compose -f /opt/vaultwarden/docker-compose.yml start vaultwarden

Запускайте цю операцію з cron щоночі та копіюйте .tgz за межі сервера. Резервна копія, яка зберігається лише на сервері, який ви захищаєте, не є резервною копією. Надійний спосіб передавання — щоночі створювати резервну копію restic на інший сервер або в об’єктне сховище. У такому разі архів шифрується, а повторювані знімки дедуплікуються автоматично. Кнопка Backup Database в адміністративній панелі зручно створює оперативну копію лише файлу SQLite, але не містить вкладень і ключів.

Тепер виконайте дію, яка відрізняє справжню резервну копію від неперевіреної: один раз відновіть її та переконайтеся, що вона працює:

mkdir -p /tmp/vw-restore
tar xzf /root/vw-backups/vw-2026-07-15.tgz -C /tmp/vw-restore
docker run --rm -p 127.0.0.1:8888:80 -v /tmp/vw-restore:/data vaultwarden/server

З ноутбука створіть тунель до сервера за допомогою ssh -L 8888:127.0.0.1:8888 you@your-vps і відкрийте http://localhost:8888 (або http://127.0.0.1:8888). Оскільки loopback-адреси вважаються безпечним контекстом, crypto.subtle доступний, а сховище тут розшифровується через звичайний http. Це єдиний тип адрес, для якого такий доступ дозволений. Увійдіть за допомогою основного пароля та переконайтеся, що ваші записи присутні. Якщо вони є, це підтверджує повне відновлення бази даних, ключів RSA та основного пароля. Після цього ви зможете за кілька хвилин відновити сервіс на новому VPS. Зупиніть контейнер за допомогою Ctrl-C і видаліть /tmp/vw-restore. Використовуйте цей підхід із тунелем і для інших адміністративних вебінтерфейсів на сервері, які не повинні бути доступні з Інтернету. Так само можна підключатися до self-hosted сканера безпеки open-kritt на порту 5173.

Режими відмов і повідомлення, які ви побачите

Cannot read properties of undefined (reading 'importKey') у консолі браузера. Сховище було завантажено через http, тому crypto.subtle не визначено. Відкривайте його лише через https:// і додайте перенаправлення з HTTP на HTTPS на проксі.

This is not a recognized Bitwarden server... у клієнті. Server URL використовує http, містить помилку або сертифікат не викликає довіри. Переконайтеся, що https://vault.example.com показує дійсний замок, а потім повторно введіть URL у self-hosted settings клієнта.

/admin відхиляє правильний пароль. Хеш Argon2 втратив екранування. Усі $ у Compose-файлі мають бути $$, але одинарний $ усередині одинарних лапок у .env має залишатися без змін. Також можливо, що ви ввели хеш замість відкритого тексту пароля, якому він відповідає.

Повільна синхронізація між пристроями; консоль показує WebSocket connection to 'wss://vault.example.com/notifications/hub' failed. Проксі не передає заголовки Upgrade/Connection. Traefik робить це автоматично, а для nginx потрібні два рядки upgrade з кроку 1. Сховище продовжує працювати, але синхронізація виконується лише під час відкриття. Старого окремого порту 3012 більше немає, починаючи з v1.31.0, тому окремий маршрут WebSocket не потрібен.

Fail2ban повідомляє про блокування, але зловмисник продовжує підключатися. Блокується 127.0.0.1, оскільки IP_HEADER налаштовано неправильно, або блокування застосовано не в тому ланцюжку iptables. Встановіть chain = DOCKER-USER і banaction = iptables-allports.

Оновлення

Завантажте новий образ і пересоздайте контейнер. Іменований том і всі ваші дані збережуться:

docker compose pull
docker compose up -d

Vaultwarden часто випускає нові версії. Стежте за примітками до релізів проєкту, а не фіксуйте версію patch, оскільки деякі релізи містять примітки щодо міграції. Перед будь-яким значним оновленням створіть свіжу резервну копію. Відкотити зміни можна, відновивши tarball у новий том.

FAQ

Vaultwarden — це те саме, що Bitwarden?

Це сумісний незалежний сервер, а не офіційний сервер. Vaultwarden повторно реалізує API сервера Bitwarden мовою Rust, тому офіційні клієнти для настільних і мобільних пристроїв, браузерів і CLI працюють із ним, споживаючи значно менше ресурсів, ніж офіційний стек. Формат сховища однаковий, тому можна виконати міграцію в будь-якому напрямку за допомогою експорту та імпорту.

Чи справді потрібен HTTPS, чи можна використовувати http у локальній мережі?

HTTPS потрібен для всіх випадків, крім тестування через loopback. Вебсховище Bitwarden і розширення використовують Web Crypto API браузера, доступний лише в безпечному контексті, тому через звичайний http клієнт видає помилку Cannot read properties of undefined і не виконує вхід. Працюють лише адреси loopback, наприклад http://localhost або http://127.0.0.1, тому на кроці 8 для тестування відновлення використовується SSH-тунель.

Як заборонити стороннім користувачам реєструватися на моєму сервері?

Установіть SIGNUPS_ALLOWED: "false" у Compose-файлі та виконайте docker compose up -d одразу після створення власного облікового запису. Після цього додавайте нових користувачів за допомогою кнопки Invite User у /admin. Для цього потрібно налаштувати SMTP, щоб вони отримували посилання для запрошення. Періодично перевіряйте список користувачів адміністратора, щоб виявити неочікувані облікові записи.

Як створити резервну копію сховища Vaultwarden?

Ненадовго зупиніть контейнер і заархівуйте весь том vw-data, db.sqlite3, attachments/, sends/, config.json і файли rsa_key.*. Потім скопіюйте архів із сервера, бажано за допомогою нічного cron. Копіювання активного файла SQLite під час роботи сервера може призвести до пошкодженого знімка, тому створюйте резервну копію після зупинки сервера. Найважливіше — один раз відновити її в тимчасовому контейнері та виконати вхід, щоб перевірити резервну копію до того, як почнете на неї покладатися.

Чи справді безпечно самостійно розміщувати паролі?

Так, якщо виконати три умови, описані в цьому посібнику: використовувати справжній HTTPS, вимкнути відкриту реєстрацію та налаштувати надійний токен адміністратора, а також перевірити резервні копії. Сховище шифрується на стороні клієнта вашим головним паролем, тому навіть сервер не бачить ваші паролі у відкритому вигляді. Викрадений db.sqlite3 також не розкриє ваші записи без цього пароля. Однак на сервері зберігаються адреси електронної пошти облікових записів і хеш із сіллю, отриманий із кожного головного пароля. Зловмисник може підбирати ці паролі офлайн, тому захищайте файл бази даних і всі його копії. Недоліком є те, що відтепер оновлення та резервні копії стають вашою відповідальністю. Саме тому Fail2ban і процедура відновлення тут є обов’язковими. Після їх налаштування корисним наступним кроком буде детальніше ознайомитися з тим, які саме компоненти самостійно розміщеного сховища можуть бути атаковані, оскільки самі записи шифруються на стороні клієнта, а захищати потрібно токен адміністратора та архів резервної копії.

#vaultwarden #passwords #security #docker #self-hosting