Vaultwarden

#

Установка Vaultwarden

#

Что такое менеджер паролей - кратко

#

Менеджер паролей - это приложение, которое безопасно хранит ваши логины, пароли, заметки и другие секреты в зашифрованной форме и помогает автоматически подставлять данные при входе в сайты/приложения. Преимущества: сильные уникальные пароли для каждого сервиса, генерация случайных паролей, синхронизация между устройствами, централизованное хранилище паролей и ssh-ключей, а также история изменений.

Что такое Vaultwarden

#

Vaultwarden - это легкая, быстрая и совместимая с Bitwarden реализация сервера (написана на Rust), которая реализует API Bitwarden и позволяет использовать официальные клиенты Bitwarden (браузерные расширения, мобильные/десктоп приложения) с вашим собственным сервером. Vaultwarden ориентирован на self-host развертывание (контейнеры, Docker Compose, Kubernetes и т. п.).

Хранит он не только пароли: TOTP-коды (клиент сам генерирует шестизначные коды для записи), SSH-ключи (десктопный клиент умеет работать как SSH-агент), банковские карты, личные данные для автозаполнения, защищенные заметки, вложения и Send (одноразовая передача текста или файла по ссылке), а также общие хранилища для семьи или команды - организации и коллекции.

Почему self-hosted

#

Коротко - ключевые преимущества self-hosted Vaultwarden:

• Контроль над данными: база и резервные копии находятся под вашим и только вашим контролем, не в облаке у третьих лиц.
• Конфиденциальность: отсутствие передачи метаданных/бэкап-копий на внешние сервисы. Вы и только вы контролируете ваши данные.
• Гибкость и интеграция: можно подключить LDAP/SMTP/внешнюю БД, SSO через свой identity provider, настроить резервные копии, использовать свой TLS (reverse proxy) и т.д.
• Экономия и простота: Vaultwarden легче и дешевле по ресурсам, чем upstream Bitwarden Server.

Минусы/риски: вы сами отвечаете за безопасность (обновления, TLS, бэкапы, настройка брандмауэра, ротация секретов). Но тут есть один, для кого-то спорный, момент. По каким то причинам, люди считают, что Bitwarden более безопасен, так как это коммерческий продукт. Вроде бы, на первый взгляд, звучит логично. Но по факту, облачные сервисы компаний всегда по атакой, и иногда они ее пропускают. Тот же Bitwarden часто допускал утечки, а у пользователей его облака часто эти самые облака “угоняли”. Как это не странно может показаться, ты защищаешь свою инстанцию Vaultwarden куда тщательней. И это не учитывая, что ты, только не обижайся, в принципе интереса не представляешь.

Только за 2026 год: Dashlane признал, что у части клиентов увели хранилища (TechCrunch), LastPass снова сообщил об утечке данных клиентов через подрядчика (TechCrunch), а отравленная версия Bitwarden CLI полтора часа лежала в npm и воровала токены разработчиков (The Hacker News).

И еще момент: Vaultwarden - это сервер, а клиенты официальные, от Bitwarden. Сервер вы контролируете, клиенты - нет. Поэтому клиенты ставим только из официальных магазинов и держим свежими: после обновления сервера старый клиент может перестать входить, и наоборот - новый клиент может потребовать обновления сервера.

Что изменилось с прошлой версии статьи

#

Короткий план развертывания (что сделаем)

#

1. Начнем с базового docker-compose.yml и .env - минимальный рабочий вариант из видео.
2. Захэшируем токен админки, создадим первого пользователя, закроем регистрацию и включим 2FA.
3. Разберем продвинутую конфигурацию: SMTP, логирование, SSO через Authentik, push-уведомления - вариант, который сейчас крутится у меня.
4. Пройдемся по админ-панели, регистрации пользователей и организациям.
5. Разберем бэкапы, типичные ошибки и чек-лист безопасности.

Базовая установка

#

Если вам нужен просто рабочий сервер без SSO и лишних настроек - этого варианта достаточно. Дальше в статье будет и продвинутая версия, но начать проще с этой.

Что понадобится: Docker с Compose, обратный прокси Traefik с внешней Docker-сетью proxy, точками входа web/websecure и настроенным механизмом выдачи сертификатов (в примере - resolver cloudflare), и домен, который ведет на сервер (в примере - vault.stilicho.ru). Если у вас другие имена сети, точек входа или resolver - подставьте свои. Сам Traefik здесь не устанавливаем, про него есть отдельная серия: Traefik в Docker и Traefik в LXC.

Создаем папку проекта и два файла. Данные храним в обычной папке рядом (bind mount) - так проще бэкапить и переносить.

mkdir -p ~/vaultwarden
cd ~/vaultwarden
umask 077
touch docker-compose.yml .env

# Сервисы этого Compose-проекта.
services:
  # Имя сервиса для команд docker compose.
  vaultwarden:
    # Фиксированное имя контейнера; должно быть уникальным на Docker-хосте.
    container_name: vaultwarden
    # Образ с закрепленной версией вместо меняющегося latest.
    image: vaultwarden/server:1.37.5
    # Перезапускать после сбоя и старта Docker, кроме ручной остановки.
    restart: unless-stopped
    # Подключения каталогов хоста к контейнеру.
    volumes:
      # Папка data рядом с Compose-файлом хранит данные из /data контейнера.
      - ./data:/data
    # Переменные окружения с настройками Vaultwarden.
    environment:
      # Полный адрес хранилища для доступа клиентов и формирования ссылок.
      - DOMAIN=https://vault.stilicho.ru
      # Хэш пароля админки; Compose подставляет значение из .env.
      - ADMIN_TOKEN=${VAULTWARDEN_ADMIN_TOKEN}
      # Открытая регистрация; после создания аккаунта ставим false в .env.
      - SIGNUPS_ALLOWED=${VAULTWARDEN_SIGNUPS_ALLOWED}
      # Часовой пояс контейнера; расписания задач Vaultwarden используют UTC.
      - TZ=Europe/Moscow
    # Сети, к которым подключаем контейнер.
    networks:
      # Общая с Traefik сеть proxy.
      - proxy
    # Метки для настройки маршрутизации через Docker-провайдер Traefik.
    labels:
      # Разрешаем Traefik обрабатывать этот контейнер.
      - "traefik.enable=true"
      # HTTP-маршрутизатор использует настроенную в Traefik точку входа web.
      - "traefik.http.routers.vaultwarden.entrypoints=web"
      # Принимаем HTTP-запросы к домену vault.stilicho.ru.
      - "traefik.http.routers.vaultwarden.rule=Host(`vault.stilicho.ru`)"
      # Создаем обработчик перенаправления с HTTP на HTTPS.
      - "traefik.http.middlewares.vaultwarden-https-redirect.redirectscheme.scheme=https"
      # Подключаем перенаправление к HTTP-маршрутизатору.
      - "traefik.http.routers.vaultwarden.middlewares=vaultwarden-https-redirect"
      # HTTPS-маршрутизатор использует точку входа websecure.
      - "traefik.http.routers.vaultwarden-secure.entrypoints=websecure"
      # Принимаем HTTPS-запросы к тому же домену хранилища.
      - "traefik.http.routers.vaultwarden-secure.rule=Host(`vault.stilicho.ru`)"
      # Включаем TLS для соединения клиента с маршрутизатором Traefik.
      - "traefik.http.routers.vaultwarden-secure.tls=true"
      # Используем уже настроенный в Traefik механизм выдачи сертификатов cloudflare.
      - "traefik.http.routers.vaultwarden-secure.tls.certresolver=cloudflare"
      # Передаем HTTPS-запросы сервису Traefik с именем vaultwarden.
      - "traefik.http.routers.vaultwarden-secure.service=vaultwarden"
      # Traefik обращается к HTTP-порту 80 контейнера, а не к порту хоста.
      - "traefik.http.services.vaultwarden.loadbalancer.server.port=80"
      # Для связи с контейнером Traefik использует Docker-сеть proxy.
      - "traefik.docker.network=proxy"
    # Дополнительные параметры безопасности контейнера.
    security_opt:
      # Запрещаем процессам повышать привилегии при запуске программ, например через setuid.
      - no-new-privileges:true

# Объявляем сети проекта на верхнем уровне, вне списка сервисов.
networks:
  # Имя общей Docker-сети для Vaultwarden и Traefik.
  proxy:
    # Сеть уже должна существовать; этот Compose-проект ее не создает.
    external: true

.env рядом с ним (хэш токена заполним в следующем разделе):

VAULTWARDEN_ADMIN_TOKEN=
VAULTWARDEN_SIGNUPS_ALLOWED=true

chmod 600 .env

Примечания к базовому файлу

#

• DOMAIN - полный внешний адрес хранилища, без слэша на конце. Этот же адрес указываем в клиентах. От него зависят ссылки и редиректы, а для WebAuthn (passkey, аппаратные ключи) важен правильный домен.
• ADMIN_TOKEN - токен для входа в административную панель (/admin). Без него панель недоступна. Как захэшировать токен по всем правилам - см. раздел «Безопасный ADMIN_TOKEN» ниже.
• SIGNUPS_ALLOWED - значение берем из .env. Разрешайте true только на время создания первого аккаунта, затем выключайте.
• Лейблы говорят Traefik, куда направлять запросы и какой сертификат использовать. Порт контейнера наружу не публикуем: Traefik обращается к нему внутри сети proxy. Web Vault требует HTTPS с доверенным сертификатом - браузер дает доступ к криптографии только в защищенном контексте.
• Версия закреплена (1.37.5): latest может измениться между записью и вашей установкой. Закрепить версию - не значит забыть про обновления: следим за релизами, делаем бэкап и обновляемся осознанно. Помогут Diun или связка Komodo, Forgejo и Renovate bot.

Безопасный ADMIN_TOKEN

#

Токен админки открытым текстом - плохая идея: Vaultwarden будет предупреждать об этом и в логах, и в самой админ-панели.

Самый простой способ захэшировать токен - встроенная команда самого Vaultwarden, не требует установки дополнительных пакетов. Запускаем ее во временном контейнере, основной сервис для этого не нужен:

docker compose run --rm --no-deps vaultwarden /vaultwarden hash --preset owasp

Команда дважды спросит отдельный длинный пароль для админки и выведет готовую строку вида $argon2id$v=19$m=...$.... Сам пароль сохраните отдельно: в админку вводится он, а не хэш.

В .env вставляем строку с одиночными $ и заключаем ее в одинарные кавычки - иначе Compose попытается подставить переменные:

VAULTWARDEN_ADMIN_TOKEN='$argon2id$v=19$m=19456,t=2,p=1$...'
VAULTWARDEN_SIGNUPS_ALLOWED=true

Если вписываете значение прямо в docker-compose.yml без .env, каждый $ нужно удвоить: $$. Одни YAML-кавычки от подстановки Compose не спасают.

Подробности есть в wiki Vaultwarden.

После этого контейнер можно запускать и проверять:

docker compose up -d
docker compose ps
docker compose logs --tail=50 vaultwarden

Учти, что «Панель /admin " - самая привлекательная цель для брутфорса; если хотите закрыть ее дополнительным rate-limiting или банить сканеры на уровне Traefik, см. статью про middlewares в Traefik и CrowdSec». А лучше вообще ограничить /admin на прокси доверенной сетью или VPN.

Регистрация первого пользователя

#

Переходим по адресу вашего Vaultwarden (в моем случае vault.stilicho.ru) и выбираем Create Account («Создать аккаунт»).

Указываем почту и nickname.

По умолчанию пароль должен быть не короче 12 символов, Vaultwarden проверяет его на сложность и предлагает проверить на утечки (не был ли такой пароль скомпрометирован ранее).

После этого попадаем в хранилище.

Сверху подсказка о трех первых шагах: создать аккаунт, установить расширение для браузера, импортировать данные из другого менеджера паролей. Формат экспорта зависит от конкретного приложения-донора, но общий принцип один: экспортируете файл там, импортируете здесь. Файл экспорта (CSV или незашифрованный JSON) содержит все секреты открытым текстом - после проверки импорта удалите его, включая корзину.

Закрываем регистрацию

#

Аккаунт есть - сразу ставим в .env:

VAULTWARDEN_SIGNUPS_ALLOWED=false

и применяем через docker compose up -d (не просто restart: только так контейнер пересоздается с новыми переменными). Проверяем в приватном окне браузера: попытка создать второй аккаунт должна закончиться отказом. Новых пользователей дальше добавляем приглашениями; для отправки писем нужен настроенный SMTP.

Двухфакторка для своего аккаунта

#

Сразу включаем 2FA в самом Vaultwarden: «Настройки» - «Безопасность» - «Двухэтапная аутентификация». Подойдет приложение-аутентификатор, passkey или аппаратный ключ. Код восстановления сохраняем вне этого хранилища, иначе получится ключ от сейфа, лежащий внутри сейфа. После настройки выходим и проверяем вход заново.

Клиенты

#

Клиенты ставим официальные, Bitwarden: расширение из магазина вашего браузера, приложение из Google Play или App Store. На экране входа выбираем Self-hosted (свой сервер), вписываем адрес https://vault.stilicho.ru, затем почту и мастер-пароль.

Первый вход в панель администратора

#

После того как контейнер запустится, можно посмотреть его логи командой docker compose logs --tail=50 vaultwarden или, например, в Portainer.

Если все в порядке, приложение не будет ругаться - значение токена надежно захэшировано. В противном случае вы увидите предупреждение, что токен указан в открытом текстовом формате и это небезопасно (на работоспособность само по себе это не влияет, но снижает защиту админ-панели).

Чтобы зайти в панель администратора, вводим в адресную строку браузера адрес Vaultwarden и обязательно добавляем в конце /admin.

Для подтверждения вводим пароль администратора - исходный пароль, а не хэш - и попадаем в панель. После нескольких неудачных попыток Vaultwarden на время блокирует вход. Выбираем вкладку General settings - это центральный раздел конфигурации.

В самом верху - напоминание, что любые значения, внесенные в настройках администратора, перезаписывают значения переменных окружения (например, данные почтового сервера) или настройки самого приложения. Значения, которые будут перезаписаны, выделены желтым.

Раздел «General settings» - подробный обзор

#

Domain

#

• Описание: Основной домен, по которому доступен Vaultwarden.
• Пример: https://vault.stilicho.ru
• Назначение: Используется в ссылках (приглашения, сброс пароля, email-уведомления, redirect для SSO).
• Важно: если поменяете домен - обновите и redirect URI в настройках вашего OIDC-провайдера.

Web Vault Enabled

#

• Описание: Включает или отключает веб-интерфейс хранилища.
• По умолчанию: включено.
• Зачем выключать: если хотите использовать Vaultwarden только через Bitwarden Desktop/Mobile клиенты.

User Registration (Allow new signups)

#

• Переменная окружения: SIGNUPS_ALLOWED
• Варианты: true - любой может зарегистрироваться; false - только вручную (админ создает пользователей через /admin или приглашения).
• Совет: на публичном сервере - выключить. Оставьте включенным временно только для регистрации первого аккаунта.

Require email verification on signups

#

• Переменная: SIGNUPS_VERIFY
• Рекомендация: включить при включенном SMTP - особенно если разрешены инвайты (INVITATIONS_ALLOWED=true), чтобы исключить опечатки в email.

Invitation (Allow invitations)

#

• Переменная: INVITATIONS_ALLOWED
• Рекомендация: оставьте включенным, если используете Organizations - иначе никто не сможет присоединиться.

SMTP Enabled

#

• Переменные: SMTP_*
• Рекомендация: настройте SMTP до создания организаций или до того, как понадобится сброс пароля.

SSO Enabled

#

• Переменная: SSO_ENABLED
• Описание: включает вход через OpenID Connect. В UI администратора можно посмотреть текущий статус подключения к провайдеру и диагностику - полезно, если что-то не срослось с SSO_AUTHORITY.

E-mail Domain Whitelist

#

• Пример: stilicho.ru,prohomelab.com
• Назначение: ограничить регистрацию корпоративными/своими доменами.

Allow password hints

#

• Рекомендация: можно отключить, чтобы не давать потенциальному злоумышленнику подсказки.

YubiKey OTPs Enabled

#

• Переменные: YUBICO_CLIENT_ID, YUBICO_SECRET_KEY
• Назначение: двухфакторная аутентификация через аппаратные ключи YubiKey.

Admin Token

#

• Описание: показывает текущий токен входа в админ-панель. Изменить можно только через переменную окружения (ADMIN_TOKEN в .env), панель не позволяет сменить его «на лету» без перезапуска контейнера.

Disable Two-Factor remember

#

• Рекомендация: включить на публичных серверах для повышения безопасности. Учтите: с недавних версий Vaultwarden «запомненные» 2FA-токены в любом случае действуют не дольше 30 дней.

Остальные настройки - по вашему желанию, но я бы отключил простую неконтролируемую регистрацию в приложении. Отключение регистрации не мешает приглашениям и SSO.

Раздел Users

#

Таблица «Users» показывает список всех пользователей хранилища, их статус, уровень подтверждения и активность. Здесь же можно приглашать новых пользователей и вручную подтверждать SSO-аккаунты, если SSO_SIGNUPS_MATCH_EMAIL не сработал автоматически.

Что такое Organization

#

Organization - группа пользователей, которые могут совместно использовать определенные записи (логины, пароли, безопасные заметки и т.п.). Аналог корпоративного или семейного хранилища в Bitwarden Cloud.

Основная идея

#

• У вас есть личный сейф, видимый только вам.
• В рамках Organization можно создавать общие коллекции, например:
  • «DevOps» - пароли CI/CD, SSH-ключи, токены API
  • «Маркетинг» - доступ к соцсетям и рекламным кабинетам
  • «Семья» - совместные подписки (Netflix, Spotify и т.п.)

Как это работает

#

1. Администратор создает организацию (например, «ProHomelab»).
2. Добавляет участников по e-mail (нужна учетка на этом же сервере - через обычную регистрацию, инвайт или SSO).
3. Создает Collections (категории для общих данных).
4. Назначает права доступа к каждой коллекции (чтение, запись, администрирование).
5. Пользователи получают эти записи в своем клиенте Bitwarden (веб, десктоп, мобильный).

Пример структуры

#

Organization: ProHomelab
 ├── Collection: Infrastructure
 │    ├── Proxmox login
 │    ├── Traefik dashboard
 │    └── Grafana API key
 ├── Collection: Media
 │    ├── Jellyfin admin
 │    └── Audiobookshelf credentials

Типы ролей

#

• Owner - полный контроль над организацией.
• Admin - управление пользователями и коллекциями.
• Manager - управляет только своими коллекциями.
• User - пользуется выданным доступом, без управления структурой.

Важные детали

#

• Organizations не обязательны для личного использования.
• Для инвайтов нужны включенные INVITATIONS_ALLOWED и настроенный SMTP.
• Можно создать несколько организаций на одном сервере.
• Поддерживаются личные ключи шифрования - админ не видит содержимое паролей участников.

Продвинутая конфигурация - .env, SSO и push-уведомления

#

Когда сервис обрастает пользователями, хочется убрать секреты из compose-файла, подключить единый вход через свой identity provider (у меня это Authentik) и получать push-уведомления на мобильных клиентах. Вот конфигурация, которая сейчас работает у меня.

docker-compose.yml

#

services:
  vaultwarden:
    container_name: vaultwarden
    image: vaultwarden/server:1.37.5
    restart: unless-stopped
    volumes:
      - /path/to/docker/vaultwarden/data:/data
      - /path/to/docker/vaultwarden/logs:/data/logs
    ports:
      - 18083:80
    environment:
      - ADMIN_TOKEN=${VAULTWARDEN_ADMIN_TOKEN}
      - SIGNUPS_ALLOWED=${VAULTWARDEN_SIGNUPS_ALLOWED}
      - SIGNUPS_VERIFY=${VAULTWARDEN_SIGNUPS_VERIFY}
      - INVITATIONS_ALLOWED=${VAULTWARDEN_INVITATIONS_ALLOWED}
      - ROCKET_WORKERS=10
      - TZ=${VAULTWARDEN_TZ}
      - LOG_LEVEL=error
      - EXTENDED_LOGGING=true
      - DOMAIN=${VAULTWARDEN_BASE_URL}
      - SMTP_HOST=${VAULTWARDEN_EMAIL__HOST}
      - SMTP_PORT=${VAULTWARDEN_EMAIL__PORT}
      - SMTP_FROM=${VAULTWARDEN_EMAIL__USERNAME}
      - SMTP_USERNAME=${VAULTWARDEN_EMAIL__USERNAME}
      - SMTP_PASSWORD=${VAULTWARDEN_EMAIL__PASSWORD}
      - SMTP_SECURITY=${VAULTWARDEN_EMAIL__SECURITY}
      - SSO_ENABLED=true
      - SSO_AUTHORITY=https://authentik.domain.ru/application/o/vaultwarden/
      - SSO_CLIENT_ID=${VAULTWARDEN_SSO_CLIENT_ID}
      - SSO_CLIENT_SECRET=${VAULTWARDEN_SSO_CLIENT_SECRET}
      - SSO_SCOPES=openid email profile offline_access   # без кавычек - иначе кавычки станут частью значения
      - SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
      - SSO_CLIENT_CACHE_EXPIRATION=0
      - SSO_SIGNUPS_ALLOWED=false     # новых аккаунтов через SSO не создаем
      - SSO_ONLY=false            # true -полностью отключает вход по мастер-паролю, только SSO
      - SSO_SIGNUPS_MATCH_EMAIL=true  # первый вход через SSO привязывается к существующему аккаунту по email
      - PUSH_ENABLED=true
      - PUSH_INSTALLATION_ID=${VAULTWARDEN_PUSH_INSTALLATION_ID}
      - PUSH_INSTALLATION_KEY=${VAULTWARDEN_PUSH_INSTALLATION_KEY}
      - PUSH_RELAY_URI=https://api.bitwarden.eu
      - PUSH_IDENTITY_URI=https://identity.bitwarden.eu
    networks:
      - vaultwarden
    # Reverse-proxy настраивается отдельно - см. раздел про Traefik/Nginx ниже.
    # Пример лейблов для Traefik (если контейнер в одной сети с прокси):
    #labels:
    #  - "traefik.enable=true"
    #  - "traefik.http.routers.vaultwarden.entrypoints=web"
    #  - "traefik.http.routers.vaultwarden.rule=Host(`vaultwarden.domain.ru`)"
    #  - "traefik.http.middlewares.vaultwarden-https-redirect.redirectscheme.scheme=https"
    #  - "traefik.http.routers.vaultwarden.middlewares=vaultwarden-https-redirect"
    #  - "traefik.http.routers.vaultwarden-secure.entrypoints=websecure"
    #  - "traefik.http.routers.vaultwarden-secure.rule=Host(`vaultwarden.domain.ru`)"
    #  - "traefik.http.routers.vaultwarden-secure.tls=true"
    #  - "traefik.http.routers.vaultwarden-secure.service=vaultwarden"
    #  - "traefik.http.services.vaultwarden.loadbalancer.server.port=80"
    #  - "traefik.docker.network=proxy"
    security_opt:
      - no-new-privileges:true

networks:
  vaultwarden:
    external: true

.env-файл

#

Секреты и то, что часто меняется между окружениями, выносим в .env рядом с docker-compose.yml:

VAULTWARDEN_ADMIN_TOKEN='<захэшированный токен в одинарных кавычках, см. раздел выше>'

# Временные настройки для первой регистрации
VAULTWARDEN_SIGNUPS_ALLOWED=false
VAULTWARDEN_SIGNUPS_VERIFY=true
VAULTWARDEN_INVITATIONS_ALLOWED=true

# Почта для уведомлений
VAULTWARDEN_EMAIL__HOST=smtp.gmail.com
VAULTWARDEN_EMAIL__PORT=465
VAULTWARDEN_EMAIL__USERNAME=<ваш email/логин SMTP>
VAULTWARDEN_EMAIL__PASSWORD="<пароль приложения>"
VAULTWARDEN_EMAIL__SECURITY=force_tls  # варианты: starttls, force_tls, off

# SSO (Authentik)
VAULTWARDEN_SSO_CLIENT_ID=<client id из Authentik>
VAULTWARDEN_SSO_CLIENT_SECRET=<client secret из Authentik>

# Push-уведомления
VAULTWARDEN_PUSH_INSTALLATION_ID=<installation id с bitwarden.com/host>
VAULTWARDEN_PUSH_INSTALLATION_KEY=<installation key с bitwarden.com/host>

# Локаль
VAULTWARDEN_TZ=Europe/Moscow

# Базовый URL (для корректной работы подтверждения email и SSO redirect)
VAULTWARDEN_BASE_URL=https://vaultwarden.domain.ru

Что изменилось по сравнению с базовым вариантом

#

Настройка SSO через Authentik

#

Vaultwarden поддерживает вход через OpenID Connect - можно завести Authentik, Keycloak, Authelia или любой другой OIDC-совместимый провайдер. Общая логика одинакова, ниже - на примере Authentik.

Scope с подтвержденной почтой

#

Vaultwarden связывает вход через SSO с аккаунтом по почте и ждет от провайдера email_verified: true. Для этого в Authentik создаем свой scope, как описано в документации Authentik по интеграции с Vaultwarden.

Customization - Property Mappings - Create - Scope Mapping:

• Name: понятное имя, например Vaultwarden Email Scope;
• Scope name: email - это имя потом стоит в SSO_SCOPES;
• Expression:

return {
    "email": request.user.email,
    "email_verified": True,
}

Application и провайдер

#

1. Applications - Applications - Create With Provider. Имя Vaultwarden, slug формируется автоматически (vaultwarden, отсюда и SSO_AUTHORITY=.../application/o/vaultwarden/). Launch URL лучше прописать руками - адрес вашего Vaultwarden.
2. Provider - тип OAuth2/OpenID Provider. Authorization flow: default-provider-authorization-explicit-consent - Authentik будет явно спрашивать разрешение на вход в приложение. Client type: Confidential.
3. Redirect URIs - режим Strict, тип Authorization, адрес вида https://vault.stilicho.ru/identity/connect/oidc-signin (домен Vaultwarden плюс этот путь).

4. Advanced protocol settings - Access Token Validity: по умолчанию minutes=5. С таким маленьким значением вход через SSO работает плохо - ставьте 10-15 минут, но не меньше 10.

5. Scopes - Selected Scopes: убираем стандартный authentik default OAuth Mapping: OpenID 'email', добавляем свой Vaultwarden Email Scope и обязательно offline_access. Без offline_access Vaultwarden не получит refresh-токен, и вас будет выкидывать.

6. Bindings - при желании ограничьте, каким пользователям и группам Authentik разрешен вход в приложение.
7. Скопируйте Client ID и Client Secret - они идут в VAULTWARDEN_SSO_CLIENT_ID и VAULTWARDEN_SSO_CLIENT_SECRET. Их всегда можно посмотреть заново в настройках провайдера.

Переменные SSO

#

Блок из видео - добавляется в environment базового compose:

      # Включаем вход через OIDC-провайдера.
      - SSO_ENABLED=true
      # Адрес issuer провайдера Authentik для приложения vaultwarden.
      - SSO_AUTHORITY=https://authentik.stilicho.ru/application/o/vaultwarden/
      # Идентификатор OIDC-клиента из .env.
      - SSO_CLIENT_ID=${VAULTWARDEN_SSO_CLIENT_ID}
      # Секрет OIDC-клиента из .env.
      - SSO_CLIENT_SECRET=${VAULTWARDEN_SSO_CLIENT_SECRET}
      # Запрашиваем идентификацию, почту, профиль и обновление токенов через offline_access.
      - SSO_SCOPES=openid email profile offline_access
      # Разрешаем связать SSO с существующим аккаунтом по совпадающей почте.
      - SSO_SIGNUPS_MATCH_EMAIL=true
      # Не принимаем неизвестный статус подтверждения почты от провайдера.
      - SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
      # Запрещаем создание новых аккаунтов через SSO, независимо от обычной регистрации.
      - SSO_SIGNUPS_ALLOWED=false
      # Оставляем обычный вход по почте и мастер-паролю наряду с SSO.
      - SSO_ONLY=false

• Слэш в конце SSO_AUTHORITY для Authentik обязателен - адрес должен буква в букву совпадать с issuer провайдера. Vaultwarden сам подтянет .well-known/openid-configuration.
• SSO_SCOPES - без кавычек. В списочной записи environment кавычки становятся частью значения, и SSO молча перестает работать.
• SSO_SIGNUPS_MATCH_EMAIL=true - если у пользователя уже есть аккаунт в Vaultwarden, первый вход через SSO привяжется к нему по email, а не создаст дубликат. Поэтому доверяем только своему провайдеру с подтвержденными адресами и оставляем SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false - не отключайте эту проверку просто ради того, чтобы убрать ошибку входа.
• SSO_SIGNUPS_ALLOWED=false отдельно закрывает создание аккаунтов через SSO: обычная регистрация и регистрация через SSO - разные настройки, закрыть нужно обе.
• SSO_ONLY оставляйте false, пока не убедитесь, что вход через SSO точно работает - иначе рискуете остаться без доступа, если что-то пойдет не так на стороне провайдера.

Применяем: docker compose up -d --force-recreate, смотрим логи.

Проверка входа

#

Проверяйте в приватном окне: в обычном браузер уже помнит вашу сессию Authentik. На странице входа появилась кнопка «Использовать единый вход» - нажимаем, вводим почту, логинимся в Authentik и подтверждаем доступ.

После этого Vaultwarden все равно спрашивает мастер-пароль - так и должно быть. Authentik подтверждает, кто вы, а хранилище расшифровывается отдельно: доступ к Authentik сам по себе не дает ключ от сейфа. Но защищать провайдер все равно нужно - это важная часть цепочки входа.

Push-уведомления

#

PUSH_ENABLED включает push-уведомления на мобильных клиентах Bitwarden: добавили запись на компьютере - приложение получает уведомление и подтягивает обновление, обычно за несколько секунд (зависит от сети и ограничений фоновой работы телефона). Ручная синхронизация работает и без push.

Для этого нужны PUSH_INSTALLATION_ID и PUSH_INSTALLATION_KEY - их бесплатно выдают на bitwarden.com/host после регистрации self-hosted инсталляции: вводим почту админа, выбираем регион (US или EU) и получаем Installation ID и Key.

Блок из видео - добавляется в environment базового compose, ключи в .env:

      # Включаем мобильные push-уведомления через инфраструктуру Bitwarden.
      - PUSH_ENABLED=true
      # Installation ID с bitwarden.com/host подставляется из .env.
      - PUSH_INSTALLATION_ID=${VAULTWARDEN_PUSH_INSTALLATION_ID}
      # Секретный Installation Key из .env.
      - PUSH_INSTALLATION_KEY=${VAULTWARDEN_PUSH_INSTALLATION_KEY}
      # Адрес push-релея для ключей региона EU.
      - PUSH_RELAY_URI=https://api.bitwarden.eu
      # Адрес сервиса авторизации Bitwarden в том же регионе EU.
      - PUSH_IDENTITY_URI=https://identity.bitwarden.eu

Регион ключей и релея должен совпадать. PUSH_RELAY_URI/PUSH_IDENTITY_URI в примере указывают на европейский релей (api.bitwarden.eu / identity.bitwarden.eu) - ключи для него получаем с выбором региона EU. Для ключей региона US эти две строки можно убрать: по умолчанию используются api.bitwarden.com / identity.bitwarden.com.

Сборка Bitwarden для Android из F-Droid может не поддерживать этот механизм push. И это не полная независимость от облака: релей передает только сигнал об изменении, сами данные клиент синхронизирует с вашим сервером, но в доставке уведомлений участвует внешняя инфраструктура.

Пользовательские настройки (User Settings)

#

Пользовательские настройки - то, что видит обычный пользователь Vaultwarden после входа в веб-интерфейс (Web Vault) по адресу https://vaultwarden.<ваш-домен>.ru.

Разберем раздел Vaults - «сердце» всей системы, где хранятся и управляются пароли, токены, заметки и другие секреты.

💡 Чтобы не путать:

• Vaults - личное хранилище (и общие через Organizations).
• Settings - настройки поведения хранилища.
• Admin Panel (/admin) - серверные параметры.

Основная структура

#

1. Items (элементы хранилища)

#

Каждый элемент содержит имя, тип, поля (username, password, URL и пр.), при желании - TOTP-код, вложения, заметки, привязку к Organization/Collection.

2. Collections

#

Если вы участвуете в Organization, в левой панели появится список Collections - общих папок с записями, доступными группе пользователей. Без организации эти секции не отображаются.

3. Навигационные вкладки

#

4. Добавление новых записей

#

Кнопка + New Item открывает форму создания записи. Доступны «Generate password» (встроенный генератор), «Add TOTP» (одноразовый 2FA-код), «Attach file» (вложения).

5. Поиск и фильтрация

#

Поиск по названию, имени пользователя, домену, заметкам - выполняется локально, данные не передаются серверу в открытом виде. Фильтры: по типу элемента, по организации/коллекции, по меткам.

6. Папки (Folders)

#

Личная логическая структура, не связанная с организациями. Данные в папке не передаются другим пользователям, даже если у них та же организация.

7. Trash (Корзина)

#

Удаленные записи не исчезают сразу - попадают в корзину, откуда их можно восстановить или удалить навсегда.

8. Context menu записи

#

View, Edit, Clone, Move to Folder/Collection, Add Favorite, Delete.

9. Password Generator

#

Генерация пароля нужной длины и сложности (буквы, цифры, символы, исключение похожих знаков) - доступен прямо из Vault.

Резервное копирование

#

В интернете можно часто встретить вопрос, как именно бэкапить Vaultwarden. Менеджер паролей без бэкапа - бомба с таймером: умер диск, и вы не можете войти никуда.

Для SQLite можно сделать консистентную копию самой базы без остановки сервиса через sqlite3 .backup. Но это еще не весь бэкап: отдельно нужны вложения, Send, config.json, ключи сервера (rsa_key*), а без docker-compose.yml и .env восстановить ту же установку сложнее. Для небольшого домашнего сервера самый понятный вариант полной копии - короткая остановка контейнера и архив всего каталога данных вместе с настройками запуска:

cd ~/vaultwarden
umask 077
mkdir -p ~/backups/vaultwarden
backup="$HOME/backups/vaultwarden/vaultwarden-$(date +%F-%H%M%S).tar.gz"
docker compose stop vaultwarden
if sudo tar -czf "$backup" data docker-compose.yml .env; then
  docker compose up -d vaultwarden
  sudo tar -tzf "$backup" >/dev/null
else
  docker compose up -d vaultwarden
  echo "Ошибка резервного копирования" >&2
  exit 1
fi

Повесьте это на cron (например, раз в сутки), оформив скриптом с абсолютными путями, проверкой ошибок и контролем свободного места. Старые копии этот пример не удаляет - ротацию добавьте сами.

• Архив содержит все секреты и не зашифрован. Бэкап должен уезжать с сервера - на NAS, в другое место, в облако - и перед отправкой обязательно шифруется. Для этого подойдут Duplicati или Zerobyte.
• Пароль от бэкапа и коды восстановления 2FA храните вне Vaultwarden - так, чтобы добраться до них, когда сервер недоступен.
• Обязательно проверьте, что бэкапы реально восстанавливаются - «бэкап, который никогда не разворачивали», как известно, это просто файл, занимающий место. Разверните архив в отдельную папку и отдельный проект с той же версией образа, не подключая к рабочему домену и Traefik, не используя тот же container_name и не перезаписывая рабочий data. Откройте хранилище, проверьте вход, несколько записей и вложения.

Если используете PostgreSQL/MySQL - соответственно pg_dump/mysqldump вместо копирования файла SQLite.

Типичные ошибки

#

• Не совпадает DOMAIN с реальным HTTPS-адресом - это ломает подтверждение email и TOTP/2FA. Проверьте, что значение точно совпадает с тем, что видит браузер (включая протокол, без завершающего слэша).
• В compose остались WEBSOCKET_ENABLED и ROCKET_ENV из старых гайдов - их можно удалить: WebSocket идет через основной HTTP-порт, отдельный порт 3012 больше не нужен.
• SSO редиректит на ошибку - не совпадает redirect URI в настройках OIDC-провайдера с реальным адресом Vaultwarden, либо SSO_AUTHORITY не совпадает с issuer провайдера (для Authentik - нужен слэш в конце).
• SSO молча не работает - SSO_SCOPES записан в кавычках внутри списочного environment.
• После входа через SSO выкидывает - в провайдере не выбран scope offline_access или слишком маленький Access Token Validity (5 минут по умолчанию; ставьте 10-15).
• Не приходят push-уведомления - устаревшие или неверные PUSH_INSTALLATION_ID/PUSH_INSTALLATION_KEY, либо выбран не тот регион релея (.com вместо .eu или наоборот).
• Предупреждение про открытый ADMIN_TOKEN в логах - токен не захэширован, см. раздел про vaultwarden hash --preset owasp.
• В логах вместо IP клиента адрес Traefik или Cloudflare - проверьте цепочку передачи IP: доверенные forwarded-заголовки на Traefik, а на Vaultwarden - IP_HEADER и IP_HEADER_TRUSTED_PROXIES. Доверять заголовкам от всех подряд нельзя: подмененный IP ломает ограничения входа и блокировки.

Чек-лист безопасности

#

• Регистрация выключена (SIGNUPS_ALLOWED=false, при SSO - и SSO_SIGNUPS_ALLOWED=false).
• Токен админки захэширован.
• 2FA включена на вашем аккаунте - TOTP, passkey или аппаратный ключ; код восстановления лежит вне этого хранилища.
• Сервер обновляется: подписка на релизы на GitHub, Diun или Komodo сообщат о новой версии.
• Клиенты на телефоне и в браузере тоже свежие.
• Админка /admin ограничена на прокси: доступ только из доверенной сети или через VPN. CrowdSec можно добавить как дополнительную защиту, но он не заменяет ограничение доступа.
• Если включен SSO, создание аккаунтов через него закрыто, а обычный резервный вход проверен и защищен 2FA.
• Бэкап есть, и вы проверили, что он восстанавливается.

FAQ

#

Можно ли использовать Vaultwarden без своего домена? Технически да (по IP), но Web Vault требует защищенного контекста (HTTPS) для Web Crypto API, а без домена сложнее получить нормальный TLS-сертификат. По факту - без реального домена система не взлетит.

Обязательно ли использовать SSO? Нет, это опциональная надстройка. Обычная регистрация с мастер-паролем работает и без него. Более того, использование SSO не отключает встроенную аутентификацию, а мастер-пароль для расшифровки хранилища нужен в любом случае.

Можно ли перенести данные из Bitwarden Cloud? Да - экспортируете хранилище из Bitwarden Cloud (Settings → Export Vault) и импортируете в свежесозданный аккаунт на Vaultwarden.

Что делать, если забыл ADMIN_TOKEN? Сгенерировать новый через vaultwarden hash --preset owasp и обновить .env/переменную окружения, затем пересоздать контейнер (docker compose up -d). К пользовательским данным это отношения не имеет.

Итого

#

К сожалению, в одной статье невозможно описать все возможности этого замечательного приложения, поэтому подробнее обо всех настройках можно почитать в официальной документации Vaultwarden: все настройки 1.37.5, SSO через OpenID Connect, push-уведомления, резервное копирование.