vps-forge: وكلاء الذكاء الاصطناعي بصلاحيات root على VPS يحصلون على تراجع تلقائي، وحالات الحظر الذاتي تنخفض من 7 من 60 إلى 0

يثبّت الوكيل الذي يملك صلاحيات root على VPS جديد أداة fail2ban، ويتحقق من الدخول بالمفتاح، ثم يجرّب كلمة المرور، وعند المحاولة الخامسة الفاشلة يحظر عنوان IP الذي تصدر منه الاختبارات. أي عنوانكم أنتم. بعد ذلك تنتهي مهلة كل الأوامر، وتبحثون عن وحدة التحكم عبر الويب في لوحة المستضيف. في اختبار مؤلف مشروع vps-forge، حظر Claude Opus 5.5 نفسه في 7 تشغيلات من 60 عندما لم يتلقَّ أي تعليمات. النموذج ذكي، لكن لم يخبره أحد بإضافة عنوانه إلى ignoreip قبل أول تشغيل لـ fail2ban.

vps-forge مهارة وكيل مفتوحة (Agent Skill): مجموعة تعليمات وسكربتات bash يحمّلها Claude Code وCodex وCursor وغيرها من الوكلاء عندما يدور الحديث عن خادم. التثبيت: `npx skills add mountain-beaver/vps-forge -g`. تتوفر إضافة (plugin) لـ Claude Code، وأرشيف zip لـ Claude.ai.

لماذا لا تنجح عبارة «كن حذراً»

ملف sshd_config المعطوب يبدو سليماً. الأمر `sshd -t` لا يُظهر شيئاً، وإعادة التحميل (reload) تمر بنجاح، والجلسة الحالية قائمة، بينما الدخول الجديد مغلق فعلاً. مثال ذلك `AllowUsers deploy` في خادم أنتم فيه المستخدم admin، أو AllowGroups التي نسيتم إضافة أنفسكم إليها.

وللوكلاء فخّهم الخاص. فهم يبقون على اتصال واحد عبر ControlMaster، فيجري الفحص `ssh host true` عبر القناة القديمة. ولا يمسّ هذا الفحص sshd الجديد ولا قواعد الجدار الناري الجديدة: يظهر الفحص أخضر، ومع ذلك لا يمكن الدخول. وتعليمة «تحقق من الدخول عبر اتصال جديد» لا تنقذ الموقف إذا فقد الوكيل الوصول بالفعل. المطلوب آلية تعمل من دونه.

دواسة «الرجل الميت» لـ sshd

قبل كل تعديل على SSH أو الجدار الناري أو sudo أو PAM، ينفّذ الوكيل `vps-forge-deadman arm`. يلتقط السكربت لقطة (snapshot) من ملفات الإعداد ويشغّل مؤقت systemd مدته 5 دقائق. يعدّل الوكيل الإعداد، ثم يدخل من جديد عبر `ssh -o ControlPath=none`، وإذا نجح الدخول ينفّذ disarm. وإذا لم ينجح، فلا حاجة إلى فعل شيء: بعد 5 دقائق يعيد المؤقت كل شيء إلى ما كان عليه.

على الورق هذه 20 سطراً من bash، لكنها صارت في النهاية عدة مئات. وخلف كل سطر تقريباً عطل سابق:

• إعادة التشغيل. مؤقت systemd-run يعيش في الذاكرة ويختفي مع الخادم. الآن يفعّل arm أيضاً وحدة (unit) ترى عند الإقلاع حالة «مفعّل لكن لم يُلغَ» فتُجري التراجع بنفسها.
• nftables. كان التراجع يوقف خدمة كانت معطّلة قبل arm، وفي ExecStop يوجد `nft flush ruleset`. فكانت تختفي مع القاعدة المطلوبة قواعد ufw وحظر fail2ban وسلاسل Docker. الآن تُحذف فقط الجداول الموجودة في الإعداد المراد التراجع عنه.
• اللغة الروسية في ufw. كان السكربت يبحث عن السطر `Status: active`، بينما يكتب ufw «Состояние: активен». فكان الجدار الناري يُعدّ معطّلاً ويُعطَّل عند التراجع. يُعالَج ذلك بـ `LC_ALL=C`.
• الحظر بعد التراجع. عادت ملفات الإعداد لكن بقي عنوان IP محظوراً. الآن يحفظ arm عنوان عميل SSH، ويرفع التراجع الحظر عنه. تحت sudo لا يوجد المتغير SSH_CLIENT، فيُؤخذ العنوان من بيئة العملية الأم.

كل هذا يُختبر في CI: حاوية بنظام systemd حقيقي، يكسر الاختبار فيها sshd والجدار الناري وfail2ban، ثم يعيد تشغيل الحاوية وهي في الحالة المفعّلة ويتحقق من الاستعادة. أما الجدار الناري في لوحة المزوّد فلا يمكن التراجع عنه لأنه خارج الخادم. وهنا لا ينفع إلا الترتيب: إضافة القاعدة الجديدة أولاً، ثم التحقق من الدخول، ثم إزالة القديمة.

عقبات صور السحابة والاختبار

أخطرها cloud-init. ففي كثير من خوادم VPS يوجد الملف `50-cloud-init.conf` وفيه `PasswordAuthentication yes`. يأخذ sshd أول قيمة يقرؤها، وتُقرأ الملفات بالترتيب الأبجدي، لذا فإن النصيحة الشائعة باستخدام `99-hardening.conf` لا تفعل شيئاً. يُسمّى ملف المهارة `00-vps-forge.conf`، ويُتحقق من النتيجة عبر `sshd -T`. وهناك أيضاً: لا يوجد auth.log في Debian 12، وينشر Docker المنافذ متجاوزاً ufw، وفي صورة Oracle Cloud قاعدة REJECT خاصة في iptables، ويتصل Coolify بمضيفه عبر SSH بحساب root، فيعطّل `PermitRootLogin no` عملية النشر.

بيئة الاختبار: أجهزة افتراضية حقيقية في QEMU (Debian 12 و13، وUbuntu 22.04 و24.04 و26.04)، وأربعة سيناريوهات، كل منها ثلاث مرات دون المهارة ومعها، أي 120 تشغيلاً لـ Opus 5.5. يفحص المحكِّم الخادم من الخارج قبل إعادة التشغيل وبعدها. دون المهارة حصل النموذج على 79–92 نقطة من 100، ومعها على 99–100.

• ssh-audit دون إخفاقات: 4/60 دون المهارة، 60/60 معها
• تنبيه عند الدخول عبر SSH: 16/30 و30/30
• الجدار الناري مفعّل: 46/60 و60/60
• حظر تخمين كلمات المرور: 50/60 و60/60
• منع root من الدخول: 30/60 و57/60
• الوكيل حظر نفسه: 7/60 و0/60
• فقدان الوصول: 0/60 و0/60

يذكر المؤلف نقاط الضعف بصراحة. الخادم غير المعدَّل يحصل على 25–42 نقطة. نحو 70% من الفارق تأتي من ثلاثة فحوص تتطابق مع إعدادات المهارة نفسها: ssh-audit نظيف، ومنع root، والتنبيه. وقد كتب المحكِّم والمهارة شخص واحد، أما أداة Lynis المستقلة فلا تكاد تتحرك: 69 و71، و72 و72، و64 و72، و73 و72. واستُخدمت ثلاثة سيناريوهات من أربعة أثناء تحسين المهارة. والنموذج المختبَر واحد فقط، إضافة إلى أربع تشغيلات يدوية لـ GLM-5.3. ولم يُثبت الاختبار فاعلية التراجع: فلم يفقد أحد الوصول، حتى دون المهارة.

الكلفة وطريقة الاستخدام

المهارة أبطأ وأغلى بنحو ثلاثة أضعاف: $1.87 مقابل $0.62 للتشغيل الواحد. والفائدة الفعلية المتبقية هي fail2ban الذي يحظر فعلاً على خادم عامل (6 من 15 دون المهارة، و15 من 15 معها)، وجدار ناري مفعّل، وصفر حالات حظر ذاتي.

والممارسة العملية كالتالي. قبل أول تعديل على SSH تأكدوا من أن الوكيل نفّذ `vps-forge-deadman arm`: إن لم يفعل، فلم تُحمَّل المهارة ولا توجد شبكة أمان. يعمل السكربت أيضاً دون وكيل، ويمكن اختباره يدوياً على خادم غير مهم: فعّلوه لدقيقة، وضعوا `AllowUsers deploy`، وتأكدوا من انغلاق الدخول، وانتظروا حالة ROLLED BACK. ومع ذلك تبقى لقطة (snapshot) لدى المزوّد والوصول إلى وحدة التحكم ضروريين. نظام RHEL غير مدعوم بعد، ولا تمسّ المهارة عُقد Kubernetes. الشيفرة بترخيص MIT ودون تتبّع عن بُعد (telemetry)، وبيئة الاختبار موجودة في المجلد bench/ ضمن مستودع mountain-beaver/vps-forge.