في 5 تشرين الثاني 2026 نشرت Alpine Linux تحذيراً أمنياً عاجلاً، وأصدر فريق OpenSSH في اليوم نفسه الإصدار 10.6p2: من يصل إلى منفذ SSH على خادم Alpine متأثر يستطيع أن يدخل إلى حساب لا كلمة مرور له، دون أن يعرف أي كلمة مرور. يكفيه اتصال واحد، وينجح في كل مرة. والخلل يطال كل إصدارات Alpine من 3.16 حتى 3.24 وفرع edge، وAlpine أساس كثير من الخوادم الخفيفة وصور الحاويات. ولم يكن للثغرة رقم CVE حتى 5 تشرين الثاني. في هذا المقال: كيف يعمل الخلل، وكيف تعرف إن كان خادمك متأثراً، وكيف تحدّثه أو تحميه مؤقتاً، وكيف تبحث عن أثر دخول سابق.
01ما الذي حدث
أبلغ الباحث Özgün Kültekin من شركة Wakefield فريق OpenSSH عن الخلل، فأصدر الفريق الإصلاح في OpenSSH 10.6p2، ونشرت Alpine حزماً مرقّعة لكل إصداراتها من 3.16 حتى 3.24 ولفرع edge في اليوم نفسه. ويقول فريق OpenSSH إن أصل الخلل خارج sshd، في طريقة النظام في التحقق من كلمات المرور، لكنه يُستغل عبر sshd، فوضع الفريق حاجزاً داخل sshd يمنع الاستغلال. ويطال الخلل، بحسب OpenSSH، أنظمة لينكس التي تعمل بمكتبة ويعمل فيها sshd دون PAM، وأشهرها Alpine.
02كيف يعمل الخلل
حين يعمل sshd دون ، يتحقق من كلمة المرور بنفسه: يشفّر الكلمة التي أرسلها الزائر بالدالة crypt، ثم يقارن الناتج بما هو مخزّن للحساب في ملف . والحساب الذي لا كلمة مرور له يُخزَّن له رمز النجمة *، ومعناه أن أي كلمة مرور لن تطابقه.
لكن التشفير يحتاج «ملحاً» يُقرأ من القيمة المخزّنة، والنجمة أقصر من أن تحمله، فيستعير sshd الملح من حساب آخر له كلمة مرور. وحين تفشل دالة crypt في musl مع مدخلات معيّنة، تعيد النجمة * علامةً على الخطأ. فيقارن sshd نجمة بنجمة، ويعدّ كلمة المرور صحيحة، فيدخل الزائر إلى حساب لم يُصمَّم أصلاً للدخول بكلمة مرور.
لذلك يكفي حساب واحد له كلمة مرور ليكشف كل الحسابات التي لا كلمة مرور لها. والحساب root مخزّن بالنجمة افتراضياً في Alpine منذ الإصدار 3.16 تقريباً، ومثله الحسابات التي أُنشئت للدخول بالمفاتيح وحدها.
03هل خادمك متأثر
يكون خادم Alpine متأثراً إن اجتمعت فيه الشروط الأربعة كلها:
- 01sshd دون PAM: تعمل حزمة openssh-server المبنية دون PAM، أو حزمة openssh-server-pam مع الإعداد UsePAM no.
- 02الدخول بكلمة المرور مفعّل: الإعداد PasswordAuthentication yes، وهو القيمة الافتراضية.
- 03حساب حقل كلمة مروره *: وهو الافتراضي لـ root، وللمستخدمين الذين يدخلون بالمفاتيح وحدها.
- 04حساب واحد على الأقل له كلمة مرور: أي قيمة مخزّنة تبدأ بـ $5$ أو $6$.
وهذه الأوامر تفحص الشروط الأربعة على خادمك، وتُنفَّذ بصلاحيات root:
# 1 و2: الحزمة المثبّتة، وإعدادات sshd الفعليةapk info -e openssh-server openssh-server-pamsshd -T | grep -iE '^(usepam|passwordauthentication|permitrootlogin) '# 3: الحسابات التي حقل كلمة مرورها *awk -F: '$2 == "*" { print $1 }' /etc/shadow# 4: الحسابات التي لها كلمة مرورawk -F: '$2 ~ /^\$[56]\$/ { print $1 }' /etc/shadow
إن ظهرت أسماء في نتيجة الأمرين الأخيرين معاً، وكان الدخول بكلمة المرور مفعّلاً دون PAM، فخادمك متأثر.
وماذا عن root؟
يحمي root افتراضياً الإعداد PermitRootLogin prohibit-password، الذي يمنعه من الدخول بكلمة مرور، إلا إن غيّرته إلى PermitRootLogin yes. لكن هذه الحماية لا تكفي إن وُجد حساب آخر يستطيع الدخول ثم يصير root، مثلاً عبر .
صور Alpine السحابية
صور Alpine السحابية الرسمية المبنية بـ tiny-cloud، من الإصدار 3.18.11 حتى 3.24.3، تأتي بمستخدم اسمه alpine لا كلمة مرور له، ويستطيع أن يصير root عبر doas دون كلمة مرور. الخادم المبني منها آمن عند أول إقلاع، لكنه يصير مكشوفاً فور أن تظهر عليه أي كلمة مرور بصيغة $6$، كأن يضع أحدهم كلمة مرور للدخول من الطرفية. عندها يدخل المهاجم باسم alpine، ثم يصير root. والصور المبنية من الإصدارات 3.21.10 و3.22.8 و3.23.8 و3.24.4 وما بعدها تحمل الإصلاح.
ولا تتأثر الحاويات التي لا يعمل فيها sshd، ومنها أغلب صور Docker المبنية على Alpine، ولا الأنظمة التي فيها PasswordAuthentication no أو openssh-server-pam مع UsePAM yes، ولا الحسابات المقفلة التي حقلها ! لا *، ولا الصور السحابية المعدّة بـ cloud-init، لأنها تكتب PasswordAuthentication no.
04حدّث openssh وأعد تشغيل sshd
خذ نسخة احتياطية أولاً، ثم حدّث الحزم. وتحديث الحزمة لا يعيد تشغيل sshd العامل، فيبقى يعمل بالشيفرة القديمة حتى تعيد تشغيله:
# حدّث كل الحزم، ثم أعد تشغيل sshd ليعمل بالنسخة المرقّعةapk upgrade -U -arc-service sshd restart# النسخة المثبّتة الآنapk info -v | grep '^openssh'
وقارن النسخة المثبّتة بالنسخة المرقّعة لإصدارك، أو بأحدث منها:
| إصدار Alpine | نسخة openssh المرقّعة |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
والإصدارات من 3.16 حتى 3.20 انتهى دعمها، ومع ذلك نشرت لها Alpine حزماً مرقّعة لخطورة الخلل. حدّثها اليوم، ثم خطط للانتقال إلى إصدار مدعوم. وعلى أي نظام آخر يعمل بمكتبة musl ويشغّل sshd دون PAM، حدّث OpenSSH إلى 10.6p2.
- المشكلةحدّثت الحزمة وما زال الخادم مكشوفاً
- الحلsshd العامل لم يُعَد تشغيله، فما زال يعمل بالشيفرة القديمة. نفّذ rc-service sshd restart.
- المشكلةالأمر rc-service غير موجود
- الحلغالباً أنت داخل حاوية بلا OpenRC يعمل فيها sshd مباشرة. حدّث الصورة وأعد بناء الحاوية وتشغيلها.
- المشكلةالنسخة المثبّتة أقدم من نسخة الجدول
- الحلمستودعاتك تشير إلى إصدار آخر، أو أن apk لم يحدّث فهرسه. نفّذ apk upgrade -U -a مرة أخرى، وتحقق من سطور /etc/apk/repositories.
- المشكلةلا أستطيع التحديث الآن
- الحلعطّل الدخول بكلمة المرور كما في القسم التالي، ثم حدّث في أقرب وقت.
05إن لم تستطع التحديث الآن
عطّل الدخول بكلمة المرور، فالخلل لا يعمل دونه. لكن قبل ذلك تأكد أن دخولك بمفتاح SSH يعمل، وأبقِ جلستك الحالية مفتوحة حتى تجرّب دخولاً جديداً من نافذة أخرى، كي لا تحبس نفسك خارج الخادم. ثم نفّذ بصلاحيات root:
# ملف إعداد جانبي، ثم السطر نفسه في أول الملف الرئيسي مع نسخة منه باسم .bakmkdir -p /etc/ssh/sshd_config.decho 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.confsed -i.bak -e '1i PasswordAuthentication no' \ -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \ /etc/ssh/sshd_config# افحص الإعداد، ثم أعد تشغيل sshd، ثم اقرأ القيمة الفعليةsshd -t && rc-service sshd restartsshd -T | grep -i passwordauthentication
يجب أن يطبع الأمر الأخير passwordauthentication no. والإصدارات من 3.19 فما بعد تقرأ مجلد sshd_config.d افتراضياً، أما الأقدم فتتجاهله، ولذلك يضيف الأمر sed السطر نفسه إلى أول الملف الرئيسي أيضاً.
06هل دخل أحد إلى خادمك؟
الخلل قديم في Alpine، والتحديث يغلق الباب ولا يُخرج من دخل قبله. فإن كان خادمك متأثراً، ابحث في السجلات عن دخول بكلمة مرور إلى حساب لا كلمة مرور له، مثل root أو alpine أو أي مستخدم يدخل بالمفاتيح وحدها:
# الدخول بكلمة مرور: قارن الأسماء بقائمة الحسابات التي حقلها *grep 'sshd.*Accepted password for' /var/log/messages# من استخدم doas ليصير rootgrep doas /var/log/messages# الحسابات الموجودة، وملفات المفاتيح وتواريخ تعديلهاcat /etc/passwdfind / -xdev -name authorized_keys -exec ls -l {} \; 2>/dev/null
- سطر Accepted password لحساب لا كلمة مرور له: أوضح دليل على استغلال الخلل، فهذا الحساب لا يدخل بكلمة مرور أصلاً.
- استخدام doas لم تقم به: دليل على أن من دخل حاول أن يصير root.
- مستخدمون أو مفاتيح جديدة: حساب لم تنشئه، أو مفتاح غريب في ملف authorized_keys، أو ملفات جديدة في مجلدات النظام.
07إن كنت من عملاء إليفانتي
- خادم CoreVPS: قوالب أنظمة التشغيل الجاهزة لـ CoreVPS لا تشمل Alpine، ولا يعمل أي منها بمكتبة musl، فالخادم المنشأ منها لا يمسّه هذا الخلل. لكن إن شغّلت عليه حاويات Alpine يعمل فيها sshd، فطبّق عليها ما في هذا المقال.
- استضافة cPanel: خوادم الاستضافة تعمل بنظام CloudLinux، وهو ليس مبنياً على musl، فلا يمسّها هذا الخلل، ولا يحتاج موقعك أي إجراء منك.
- إن احتجت يداً: فريق الدعم الفني معك على مدار الساعة إن احتجت مساعدة في فحص خادمك أو في ضبط الدخول بالمفاتيح.
08الدرس: مفاتيح SSH بدل كلمات المرور
هذا الخلل لا يصيب خادماً يدخل إليه الجميع بالمفاتيح. ثلاث عادات تحمي خادمك من أشباهه:
- 01المفاتيح وحدها: أعطِ كل من يدخل إلى الخادم مفتاح SSH، ثم اجعل PasswordAuthentication no إعداداً دائماً لا إجراءً مؤقتاً.
- 02منفذ SSH ليس للجميع: إن كان من يدخلون إلى خادمك يعملون من عناوين معروفة، فاسمح بها وحدها في جدار الحماية، فلا يصل المهاجم إلى المنفذ أصلاً.
- 03أعد تشغيل الخدمة بعد تحديثها: تحديث الحزمة لا يغيّر الخدمة العاملة. اجعل إعادة تشغيل الخدمة جزءاً من كل تحديث أمني.
