نشر Vaultwarden على VPS: مدير كلمات مرور ذاتي الاستضافة

لماذا تستضيف مدير كلمات المرور الخاص بك بنفسك؟

‏تُفرض رسوم على مديري كلمات المرور السحابية لكل مستخدم شهريًا، وتُخزّن خزينتك المشفرة على خوادم لا تتحكم فيها، وقد تختفي أو ترفع أسعارها فجأة. يعكس Vaultwarden هذا النموذج: حاوية واحدة على VPS الخاص بك، وحجم Docker واحد للنسخ الاحتياطي، وعدد غير محدود من حسابات المستخدمين بتكلفة بنية تحتية ثابتة. ولأن Vaultwarden يتحدث بروتوكول Bitwarden، يتصل كل عميل Bitwarden — امتداد Chrome، إضافة Firefox، iOS، Android، Windows، Linux، CLI — بمثيلك المُستضاف ذاتيًا دون أي تعديل.

المزايا الرئيسية

‏100% متوافق مع جميع عملاء Bitwarden الرسميين — لا نسخة معدّلة، ولا تطبيق خاص، ولا حاجة لإعادة التعلم
‏تشفير AES-256 من طرف إلى طرف: كلمة المرور الرئيسية لا تغادر جهازك أبدًا
‏أقل من 50 ميغابايت من الذاكرة في وضع الخمول — يعمل بسهولة على VPS بسعة 512 ميغابايت إلى جانب خدمات أخرى
مستخدمون وخزائن تنظيمية غير محدودة مع مشاركة مشفرة ووصول مستند إلى الأدوار
‏مصادقة TOTP مدمجة: استبدل Google Authenticator ببديل مُستضاف ذاتيًا
وصول الطوارئ — امنح جهة اتصال موثوقة صلاحية قراءة بعد فترة انتظار قابلة للتهيئة

المتطلبات الأساسية

‏تحتاج إلى VPS بنواة معالج واحدة على الأقل وذاكرة 512 ميغابايت مع تثبيت Docker (يُوصى بـ Ubuntu 22.04 LTS). تحتاج أيضًا إلى اسم نطاق يشير إلى VPS — يرفض عملاء Bitwarden الخزائن غير المحمية بـ HTTPS، لذا فإن HTTPS إلزامي. افتح المنفذين 80 و443 في جدار الحماية: ufw allow 80 && ufw allow 443.

‏نشر Vaultwarden في 5 خطوات

‏تثبيت Docker

‏إذا لم يكن Docker مثبتًا: curl -fsSL https://get.docker.com | sh && systemctl enable --now docker. تحقق بـ docker --version.

‏تشغيل Vaultwarden

‏شغّل الحاوية: docker run -d --name vaultwarden --restart=always -v vaultwarden:/data -p 127.0.0.1:8000:80 -e WEBSOCKET_ENABLED=true vaultwarden/server:latest. يبدأ الخادم في أقل من ثانية ويستمع على المنفذ 8000 على المضيف المحلي.

‏تهيئة HTTPS مع Caddy

‏ثبّت Caddy: apt install -y caddy. أنشئ /etc/caddy/Caddyfile بالمحتوى: passwords.your-domain.com { reverse_proxy localhost:8000 }. أعد تحميل Caddy: systemctl reload caddy. يُستصدر شهادة TLS من Let's Encrypt تلقائيًا وتُجدَّد إلى أجل غير مسمى — دون أي تهيئة.

إنشاء حسابك

‏افتح https://passwords.your-domain.com في متصفحك. انقر على "Create Account"، اختر كلمة مرور رئيسية قوية (تُشفّر كل شيء محليًا قبل إرسال أي شيء إلى الخادم)، وسيكون خزينتك نشطًا فورًا.

تقييد التسجيل

‏بعد إنشاء جميع الحسابات، أوقف الحاوية وأعد تشغيلها مضيفًا -e SIGNUPS_ALLOWED=false إلى أمر docker run. أصبح مثيلك للدعوة فقط. لإدارة المستخدمين بصفة مستمرة، فعّل لوحة الإدارة بإضافة -e ADMIN_TOKEN=$(openssl rand -base64 48).

أول تسجيل دخول

‏عند فتح الرابط لأول مرة، يعرض Vaultwarden خزينة Bitwarden على الويب: انقر على "Create account" وحدد بريدك الإلكتروني وكلمة المرور الرئيسية (لا يمكن لأحد استرجاعها، ولا حتى نحن). افعل ذلك فورًا: التسجيل مفتوح.

‏تهيئة SMTP والمصادقة الثنائية عبر البريد الإلكتروني

‏يمكن لـ Vaultwarden إرسال رسائل بريد إلكتروني للتحقق من العنوان وإعادة تعيين كلمة المرور ودعوات المنظمة والمصادقة الثنائية عبر البريد الإلكتروني (_ENABLE_EMAIL_2FA=true). تستحق هذه النقطة الأخيرة انتباهًا خاصًا: إذا لم يُهيَّأ SMTP أو كانت التهيئة خاطئة، تُعلَن المصادقة الثنائية عبر البريد الإلكتروني مفعّلة لكنها لا ترسل شيئًا — لا يصل الرمز، ولا يستطيع المستخدم تسجيل الدخول، ولا يُظهر Vaultwarden أي خطأ مرئي.

‏الخلط الأكثر شيوعًا يتعلق بالمنافذ والتشفير. قيمتان تتعايشان ولا يمكن تبادلهما:

- ‏المنفذ 465 مع SMTP_SECURITY=force_tls — اتصال TLS منذ البداية (المعروف سابقًا بـ «SMTPS»). متوافق مع معظم موفري الإنترنت والمرحّلات المؤسسية.
- ‏المنفذ 587 مع SMTP_SECURITY=starttls — اتصال بنص عادي يترقى إلى TLS عبر أمر STARTTLS. القيمة المتوقعة من معظم موفري SMTP الحديثين (‏SendGrid، Brevo، Postmark، Gmail SMTP).

‏استخدام force_tls على المنفذ 587 — أو starttls على المنفذ 465 — يُفشل اتصال SMTP بصمت: لا يُسجّل Vaultwarden شيئًا، ولا تُرسَل الرسائل، وتظهر الواجهة «تم الإرسال» إذا اختبرت من لوحة الإدارة. الإشارة الوحيدة هي غياب الرسالة عند المستلم.

‏تهيئة SMTP بشكل صحيح

اختر المنفذ والأمان بحسب موفرك

‏راجع توثيق مرحّل SMTP الخاص بك (Gmail، Brevo، Postmark، SendGrid…). القاعدة العملية: إذا حدّد موفرك المنفذ 465 → SMTP_SECURITY=force_tls؛ وإذا حدّد المنفذ 587 → SMTP_SECURITY=starttls. لا تخلط بينهما.

‏مرّر متغيرات SMTP إلى الحاوية

‏أعد تشغيل الحاوية مع المتغيرات اللازمة:

docker run -d --name vaultwarden --restart=always \
  -v vaultwarden:/data \
  -p 127.0.0.1:8000:80 \
  -e SMTP_HOST=smtp.your-provider.com \
  -e [email protected] \
  -e SMTP_PORT=587 \
  -e SMTP_SECURITY=starttls \
  -e SMTP_USERNAME=your_login \
  -e SMTP_PASSWORD=your_password \
  vaultwarden/server:latest

اختبر الإرسال من لوحة الإدارة

‏افتح https://passwords.your-domain.com/admin، انتقل إلى قسم SMTP Email Settings واستخدم زر Send test email. إذا لم تصل الرسالة خلال 60 ثانية، تحقق من سجلات الحاوية: docker logs vaultwarden 2>&1 | grep -i smtp. رسالة Connection refused تشير إلى منفذ خاطئ؛ TLS handshake error تشير إلى تعارض في الأمان.

‏فعّل 2FA عبر البريد الإلكتروني فقط بعد التحقق من الإرسال

‏لا تُفعّل _ENABLE_EMAIL_2FA=true إلا بعد تأكيد نجاح الإرسال التجريبي. إذا فعّلته قبل ذلك، لن يتلقى المستخدمون الذين يطلب عملاؤهم رمزًا أي شيء وسيُحجب عنهم الوصول. لإلغاء حجب حساب مقفل: افتح /admin، حدد المستخدم وانقر Deactivate TOTP لتعطيل 2FA مؤقتًا.

توافق العميل/الخادم والأخطاء الصامتة

‏قدّم عملاء Bitwarden الحديثون تدفق مصادقة أولي جديد يستدعي نقطة النهاية /identity/accounts/prelogin/password. لا تعرف مثيلات Vaultwarden المثبّتة على إصدار أقدم من 1.36.0 هذه النقطة وتُعيد خطأ 404 بلا رسالة صريحة — يعرض العميل فقط فشل اتصال عام. الفخ خبيث: الأجهزة المتصلة قبل تحديث العميل تستمر في العمل بشكل طبيعي، لأن جلستها مُنشأة مسبقًا ولا تمر بمسار المصادقة الجديد. الأجهزة الجديدة فقط هي التي تفشل. إذا نفّذت curl https://your-domain.com/identity/accounts/prelogin/password -X POST -d '{"email":"[email protected]"}' -H 'Content-Type: application/json' وحصلت على 404، فخادمك قديم.

أعراض عدم تطابق إصدار العميل/الخادم

تعذّر تسجيل الدخول على جهاز أو متصفح جديد بينما تعمل الأجهزة الحالية بشكل طبيعي
‏رسالة خطأ عامة بلا إشارة للسبب ("An error has occurred" أو "Invalid username or password")
‏امتداد Chrome أو Firefox المثبّت حديثًا يفشل، لكن الإصدار نفسه على جهاز آخر يعمل
‏خزينة Bitwarden على الويب المستضافة على مثيلك تُعيد 404 على /identity/accounts/prelogin/password
‏لا أخطاء في سجلات Vaultwarden من جهة الخادم — نقطة النهاية غير موجودة، لا شيء يُسجَّل
‏ظهر المشكل بعد تحديث تلقائي لعميل Bitwarden على الجهاز الجديد

تشخيص التعارض وحله

تحقق من إصدار خادمك

‏استعلم عن نقطة نهاية الإصدار: curl https://your-domain.com/api/version. إذا أظهرت الاستجابة إصدارًا أقدم من 1.36.0، فخادمك لا يدعم تدفق المصادقة الجديد لعملاء أحدث.

التحديث إلى أحدث صورة

‏الحل الأأمن هو دائمًا استخدام vaultwarden/server:latest والحفاظ على تحديث الصورة. للتحديث: docker pull vaultwarden/server:latest && docker stop vaultwarden && docker rm vaultwarden، ثم أعد تشغيل نفس أمر docker run المستخدم عند التثبيت. يحتفظ Vaultwarden بالبيانات في الحجم — لا حاجة لأي ترحيل يدوي.

تحقق من تطبيق التحديث

‏بعد إعادة التشغيل، استعلم مجددًا عن curl https://your-domain.com/api/version وأكّد أن الإصدار 1.36.0 أو أحدث. ثم اختبر تسجيل الدخول من نافذة تصفح خاص جديدة.

تثبيت إصدار بعينه إذا كانت الاستقرارية أولوية

‏إذا كنت تفضل التحكم في التحديثات يدويًا، استخدم وسمًا محددًا: vaultwarden/server:1.37.2 مثلًا. في هذه الحالة، راقب الإصدارات على GitHub وحدّث عند نشر إصدار جديد من عميل Bitwarden — الاثنان مترابطان.

‏انحدار في 1.37.1: تغيير كلمة المرور الرئيسية محظور

‏يحتوي الإصدار 1.37.1 على انحدار معروف (إشكالية GitHub ‏#7659): يُعيد طلب تغيير كلمة المرور الرئيسية HTTP 422 مع الرسالة missing field newMasterPasswordHash. تفشل العملية من جانب الخادم دون أن يُقدّم العميل معلومات مفيدة. الإصلاح في الإصدار 1.37.2 الصادر بعده بقليل. إذا ثبّتّ الإصدار 1.37.1، انتقل مباشرة إلى 1.37.2 — الأمر هو نفسه لأي تحديث: docker pull vaultwarden/server:1.37.2 && docker stop vaultwarden && docker rm vaultwarden، ثم أعد تشغيل الحاوية مع الوسم الجديد.

‏فخ SIGNUPS_ALLOWED=false: ضعه فقط بعد إنشاء أول حساب مسؤول

‏خطأ شائع عند التثبيت: وضع -e SIGNUPS_ALLOWED=false قبل إنشاء حساب المسؤول. النتيجة — مثيلك يرفض إنشاء الحساب ولا تستطيع تسجيل الدخول. الترتيب إلزامي: (1) ابدأ بدون هذا المعامل، (2) أنشئ حساب المسؤول فورًا عبر الواجهة الويب، (3) ثم فقط أعد تشغيل الحاوية مع SIGNUPS_ALLOWED=false. إذا حجبت نفسك، المخرج هو تفعيل لوحة الإدارة عبر -e ADMIN_TOKEN=$(openssl rand -base64 48) ودعوة مستخدم المسؤول من /admin.

نسخ احتياطية يومية في سطر cron واحد

‏أضف هذا إلى crontab للجذر (crontab -e): 0 3 * * * docker run --rm -v vaultwarden:/data -v /backup:/out busybox tar czf /out/vaultwarden-$(date +%F).tar.gz /data. شغّله كل يوم في الساعة 3 صباحًا — تصل الخزينة كاملة (ملف SQLite + المرفقات) إلى /backup في أرشيف مؤرشف بالتاريخ. أرسل هذا المجلد إلى S3 أو Backblaze B2 باستخدام rclone لحماية خارج الموقع.

التوثيق الرسمي

‏للتهيئة المتقدمة والخيارات الخاصة بالأداة، ارجع إلى التوثيق الرسمي لـ Vaultwarden. يغطي هذا الدليل الإعداد على VPS؛ يبقى توثيق الناشر مرجعًا للضبط الدقيق والتحديثات الكبرى وحالات الاستخدام المحددة.