كيفية تشغيل OpenClaw بأمان على خادم VPS

ما هو OpenClaw، ولماذا يجب تحصينه أولاً

OpenClaw هو وكيل ذكاء اصطناعي تستضيفه بنفسك. تشغّله على خادمك، وتربطه بنموذج لغوي كبير، ويمكنه تنفيذ أوامر shell، والتحكم في متصفح، وقراءة ملفاتك وكتابتها، والتعامل مع الرسائل التي ترسلها إليه من تطبيقات الدردشة. هذه الصلاحيات هي الغرض الأساسي من الأداة، وهي أيضاً مصدر الخطر بالكامل. فالوكيل الذي يمكنه تنفيذ أي أمر لا يكون آمناً إلا بقدر أمان الخادم الذي يعمل عليه والقيود التي تضعها عليه.

هناك حقيقتان تحددان نهج هذا الدليل. أولاً، صُمم OpenClaw بحيث تتولى أنت تحصينه. يحمّل نموذج الأمان فيه المشغّل مسؤولية وضع سياسات صارمة للأدوات، واستخدام sandboxing، وضبط الصلاحيات بعناية، بدلاً من الاعتماد على إعدادات افتراضية آمنة. ثانياً، شهد المشروع بالفعل حادثة أمنية خطيرة: ففي March 2026، كُشف عن تسع مشكلات أمنية خلال أربعة أيام، من بينها ثغرة حرجة لتصعيد الصلاحيات، وهي CVE-2026-32922، وحصلت على تقييم 9.9 من 10. لا تعني أي من الحقيقتين أنه ينبغي لك تجنب OpenClaw. بل تعني أنه لا ينبغي لك تشغيله بطريقة متهاونة، وأن هذا الدليل يشرح الطريقة الحذرة. ومن جوانب هذه الطريقة أن تحدد مسبقاً مقدار ما يمكن للوكيل تنفيذه من دون طلب تأكيد، وهو قرار تجعله Claude Code واضحاً من خلال أوضاع الصلاحيات، إذ يستحق الخادم الذي لا تجلس أمامه إعداداً أكثر تقييداً من الحاسوب المحمول الذي تراقبه.

وهناك خبر جيد أيضاً. يتخذ OpenClaw بالفعل خياراً آمناً نيابةً عنك: فـgateway الخاص به، وهو العملية الوحيدة التي تتحكم في كل شيء، يستمع افتراضياً على عنوان loopback، ولذلك لا يمكن الوصول إليه من الإنترنت ما لم تتعمد تعريضه له. يتركز معظم العمل أدناه على إبقائه بهذه الحالة والحد من نطاق الضرر إذا حدث خطأ ما.

امنح OpenClaw مستخدماً خاصاً غير مميّز

لا تشغّل أي agent بصفة root. إذا شُغِّل OpenClaw بصفة root وحدث خطأ، سواء بسبب خلل أو تعليمات سيئة أو CVE مثل الحالة المذكورة أعلاه، فلن يكون لحجم الضرر حد أقصى. أنشئ مستخدم نظام مخصصاً من دون shell لتسجيل الدخول ومن دون sudo، وشغّل agent بهذا المستخدم:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

يوجد كل ما يملكه OpenClaw ضمن /opt/openclaw، وتملك ذلك الحساب هذه الملفات. هذه أهم خطوة على الإطلاق، وهي المبدأ نفسه المشروح في تشغيل الخدمات كمستخدم غير مميّز: يمثل الحساب الذي يشغّل agent الحد الأقصى لما يمكنه إتلافه.

تثبيت OpenClaw

يُوزَّع OpenClaw كحزمة npm، لذلك ثبّت Node.js أولاً إذا لم يكن مثبتاً على الخادم. ثبّت الحزمة بشكل عام، ما يضع الملف التنفيذي openclaw في PATH لجميع المستخدمين، ثم نفّذ خطوة الإعداد الأولية لمرة واحدة:

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

يعني تنفيذ الإعداد الأولي كمستخدم openclaw أن إعدادات الوكيل ستُحفظ في دليله المنزلي، /opt/openclaw، وليس في الدليل المنزلي لـ root. يوفّر المشروع أيضاً مُثبّت curl -fsSL https://openclaw.ai/install.sh | bash ينفّذ التثبيت نفسه في سطر واحد. تخطَّ العلامة --install-daemon أثناء الإعداد الأولي؛ فهي ستسجّل خدمة OpenClaw الخاصة، بينما وحدة systemd المقوّاة التي ستنشئها أدناه أكثر صرامة.

أبقِ الـgateway على loopback وخلف جدار ناري

يرتبط الـgateway بالعنوان 127.0.0.1 افتراضياً. اتركه هناك. لا يوجد تقريباً أي سبب لنشر هذا المنفذ على الإنترنت، وفعل ذلك يمنح أي شخص يعثر عليه نقطة دخول عن بُعد إلى عملية تنفّذ الأوامر باستمرار.

ضع جداراً نارياً بسياسة منع افتراضية أمام الخادم، حتى لا تُكشَف أي خدمة عن طريق الخطأ:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

تجنّب خطأين هنا. قد يترك جدار ناري يغطي IPv4 فقط الخدمة نفسها مكشوفة بالكامل عبر IPv6، وهذه هي بالضبط ثغرة جدار IPv6 التي توقع كثيراً من الأشخاص في المشكلة. وإذا احتجت إلى الوصول إلى الـgateway من حاسوبك المحمول، فلا تفتح المنفذ. صِل إليه عبر VPN أو نفق SSH، حتى لا يستمع الـagent إلى الإنترنت المفتوح مطلقاً.

اعزل أسراره

يحتاج OpenClaw إلى مفتاح API لنموذج اللغة الذي تربطه به. يمكن لهذا المفتاح إنفاق أموالك، ويمكن للوكيل استخدامه للتصرف نيابةً عنك، لذلك عامله مثل كلمة مرور. أبقه خارج ملف الوحدة وخارج أي مستودع. ضعه في ملف لا يستطيع قراءته إلا مستخدم OpenClaw:

sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env      # add ANTHROPIC_API_KEY=... or your model provider's key

تُحمِّل وحدة systemd هذا الملف باستخدام EnvironmentFile، لذلك يصل المفتاح إلى العملية من دون ظهوره في سطر أوامر أو سجل أو سجل أوامر الصدفة. وينطبق هذا النمط على كل سر موجود على الخادم: إذ يتركز فحص التحصين لـ Vaultwarden المستضاف ذاتياً على رمز المسؤول وملف النسخ الاحتياطي، لا على التشفير، لأن أذونات الملفات هي التي تحدد فعلياً من يستطيع قراءة السر وهو مخزّن.

شغّله كخدمة systemd مقسّاة

يمنحك تشغيل الوكيل ضمن systemd إعادة تشغيل تلقائية، وسجلات واضحة عبر journalctl، والأهم مجموعة من خيارات العزل على مستوى النواة تقلل ما يمكن للعملية الوصول إليه حتى إذا تم اختراقها. أهم الخيارات للوكيل هي NoNewPrivileges حتى لا يتمكن مطلقاً من اكتساب صلاحيات جديدة، وProtectSystem=strict لجعل نظام الملفات للقراءة فقط باستثناء المواقع التي تسمح بالكتابة فيها، وPrivateTmp لإنشاء دليل مؤقت معزول خاص به، وProtectHome لمنعه من قراءة الأدلة المنزلية.

أنشئ وحدة كاملة ومقساة هنا، ثم انسخها إلى /etc/systemd/system/openclaw.service:

تبدأ الوحدة openclaw gateway، وهي العملية طويلة التشغيل التي تتحكم في الوكيل؛ إذا أظهر which openclaw مساراً مختلفاً على خادمك، فعدّل ExecStart ليتطابق معه. ستجد الشرح الكامل لهذه التوجيهات، وكذلك daemon-reload وenable --now، في تشغيل برنامج كخدمة systemd. بعد لصق الوحدة، إليك الخلاصة المختصرة:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

عزّز نقطة الدخول أيضاً

لا يكون خادم الوكيل آمناً إلا بقدر أمان الخادم المحيط به. وتكمل طبقتان إضافيتان عملية التحصين. انقل SSH إلى المصادقة باستخدام المفاتيح فقط، وعطّل تسجيل دخول root، كما هو موضح في تحصين SSH على VPS، حتى لا يتمكن المهاجمون من تخمين بيانات اعتماد الحساب الذي تستخدمه لإدارة الخادم بالقوة الغاشمة. ثم أضف Fail2ban لطرد أدوات الفحص التي تستهدف كل منفذ عام باستمرار. لا تؤثر أي من هاتين الطبقتين مباشرةً في OpenClaw، لكنهما تغلقان المسارات التي سيستخدمها المهاجم للوصول إليه.

حدّثه عمداً

تُظهر إفصاحات March 2026 بأوضح شكل ممكن أهمية البقاء على الإصدارات الحالية. تكون ثغرة تصعيد صلاحيات في agent أخطر بكثير من ثغرة مماثلة في تطبيق ويب عادي، لأن agent ينفّذ الأوامر أصلاً. راقب إصدارات المشروع، وثبّت التحديثات الأمنية بسرعة، وتعامل مع ترقية OpenClaw على أنها صيانة دورية، لا مهمة يمكن تأجيلها.

لفهم ما تقوم بتقويته أمنياً فعلياً، يشرح مخطط بنية agent على نمط OpenClaw المكوّنات المتحركة، بينما يوضّح إنشاء AI agent خاص بك على VPS البنية العامة التي يتخذها أي agent. إذا انتهى بك الأمر إلى تشغيل agent ثانٍ بجانبه، فتذكّر أن جلستي Claude Code على VPS واحد يمكن أن تمرّرا العمل بينهما، ولذلك يحتاج كل واحد منهما إلى حسابه وحدوده الخاصة، بدلاً من وراثة حسابك وحدودك.

FAQ

هل من الآمن تشغيل OpenClaw على VPS عام؟

يمكن ذلك إذا قمت بتعزيزه أمنياً. صُمّم OpenClaw ليكون قوياً؛ فهو ينفّذ أوامر shell ويتحكم في متصفح، لذلك يكون الإعداد غير الحذر خطيراً فعلاً. وقد تعرّض المشروع بالفعل لـCVE خطير، وهو CVE-2026-32922 في March 2026. يفترض نموذج الأمان فيه أن تضيف أنت، بصفتك المشغّل، القيود اللازمة. شغّله كمستخدم غير مميّز، واترك gateway الخاص به على loopback خلف جدار ناري يرفض الاتصالات افتراضياً، واعزل مفاتيح API الخاصة به، وشغّله كخدمة systemd معزّزة أمنياً.

هل ينبغي أن أعرّض gateway الخاص بـOpenClaw للإنترنت؟

لا. يرتبط gateway بـloopback افتراضياً، ويجب أن تتركه كذلك. فهو العملية الوحيدة التي تتحكم في agent، ولذلك فإن تعريض gateway يوفّر مساراً عن بُعد إلى مكوّن ينفّذ الأوامر باستمرار. إذا احتجت إلى الوصول إليه عن بُعد، فاستخدم VPN أو نفق SSH بدلاً من فتح المنفذ.

بأي مستخدم ينبغي أن يشغّل OpenClaw؟

بمستخدم نظام مخصّص لا يملك shell لتسجيل الدخول ولا sudo، وليس root مطلقاً. إذا اختُرق agent، فسيكون حساب المستخدم هو الحد الأقصى للضرر، لذلك يجب أن يملك هذا الحساب ملفاته الخاصة فقط ضمن دليل مثل /opt/openclaw، وألا يملك أي شيء آخر.

كيف أحافظ على أمان مفاتيح API الخاصة بـOpenClaw؟

خزّنها في ملف لا يستطيع قراءته إلا مستخدم OpenClaw، بالوضع 600، وحمّلها إلى الخدمة باستخدام EnvironmentFile في systemd. أبقِ المفتاح خارج ملف الوحدة، وخارج سجل shell، وخارج أي مستودع git. دوّر المفتاح إذا شككت في أي وقت في أنه تسرّب.