ما تقوله OpenSSH وAlpine وما لا تقولانه
نُشرت OpenSSH 10.6p2 في 5 نوفمبر 2026. تعلن ملاحظات الإصدار تصحيح ثغرة تجاوز لمصادقة كلمة المرور يمكن استغلالها عبر sshd على بعض أنظمة Linux المترجمة دون PAM. وفي اليوم نفسه نشرت Alpine Linux نشرة تشرح الآلية والشروط والحزم المصحَّحة. أبلغ عن الثغرة Özgün Kültekin من Wakefield.
توضيحان مفيدان قبل التحرك. أولًا، لم يكن قد أُسند أي معرّف CVE حتى تاريخ نشرة Alpine؛ تذكر بعض المقالات الصحفية معرّفًا، ولا نعتمده لغياب مصدر أولي. ثانيًا، يرى مشرفو OpenSSH أن السبب الجذري يقع خارج sshd، وقد التفّوا على المشكلة داخل sshd: فالتصحيح إذن في حزمة OpenSSH وليس في مكتبة C. حتى لحظة كتابة هذه السطور، لا نعلم بأي تقرير علني عن استغلال فعلي، لكن التفاصيل التقنية منشورة: افترض أن عمليات مسح ستتبعها.
الشروط الخمسة، وكلها لازمة
- مكتبة C من نوع musl — وهذا حال Alpine، وأنظمة مدمجة أخرى تستخدم musl مثل OpenWrt. أما Debian وUbuntu وFedora وAlmaLinux فتستخدم glibc وليست معنية.
sshdدون PAM — حزمةopenssh-serverفي Alpine مترجمة دون PAM، وكذلكopenssh-server-pamمعUsePAM no. أما معUsePAM yesفأنت غير معني.PasswordAuthentication yes— وهي القيمة الافتراضية في OpenSSH. وإن غيّرتها إلىnoفلا يمكن بلوغ الثغرة.- حساب قيمة حقل كلمة المرور فيه
*— مستخدم أُنشئ دون كلمة مرور للدخول بالمفتاح، أو مستخدم دليل تديره musl-nscd، أو المستخدمalpineفي صور السحابة الرسمية. - حساب آخر واحد على الأقل له كلمة مرور فعلية (تجزئة
$5$أو$6$) — يكفي حساب واحد لكشف جميع الحسابات التي لا كلمة مرور لها.
لماذا تكفي كلمة مرور من 257 بايت
دون PAM، يجزّئ sshd كلمة المرور المدخلة بالدالة crypt() ويقارن الناتج بالحقل المخزَّن في /etc/shadow. وفي الحسابات التي يكون حقلها أقصر من أن يتسع لملح، يستعير sshd ملح حساب آخر حتى لا يكشف زمن الاستجابة أن اسم المستخدم لا كلمة مرور له.
في musl، تعيد crypt() السلسلة * كقيمة خطأ حين يتجاوز المفتاح 256 بايت. و* هي أيضًا، في /etc/shadow، قيمة الحساب الذي لا كلمة مرور له. فتنجح المقارنة: يمر الدخول دون أن يخمّن أحد شيئًا. وتحدد نشرة Alpine النافذة القابلة للاستغلال: كلمة مرور من 257 إلى 1024 بايت. ليس هذا عيبًا تشفيريًا ولا تلفًا في الذاكرة، بل خطأ منطقي: قيمة خطأ عُدّت نتيجة.
من المعني ومن غير المعني
مرّر الجدول أفقيًا
| الإعداد | هل هو معني؟ | السبب |
|---|---|---|
| Alpine، `openssh-server`، كلمات المرور مفعّلة، حساب بـ`*` وحساب بـ`$6$` | نعم | الشروط الخمسة مجتمعة |
| Alpine، `openssh-server-pam` مع `UsePAM yes` | لا | المصادقة تمر عبر PAM وليس عبر `crypt()` داخل `sshd` |
| Alpine مع `PasswordAuthentication no` | لا | لا تُجرى أي مصادقة بكلمة مرور |
| Debian وUbuntu وAlmaLinux وRocky (glibc) | لا | المقارنة لا تتلقى قيمة الخطأ `*` |
| حاوية Alpine دون `sshd` | لا | لا توجد خدمة SSH لمهاجمتها |
| حساب مقفل بـ`!` بدل `*` | لا بالنسبة لهذا الحساب | `!` لا تطابق قيمة الخطأ |
| صورة سحابة Alpine رسمية، دون أي كلمة مرور محددة | ليس عند أول إقلاع | تعدّها النشرة قابلة للاستغلال بمجرد ظهور تجزئة `$6$`، مثلًا كلمة مرور تُحدَّد من الطرفية |
«أنا على Debian أو Ubuntu: هل يمسّني هذا؟»
لا، ليس بالنسبة إلى هذه الثغرة: فهي تشترط musl. لكن الاعتراض يستحق الطرح، لأن السؤال المفيد لأي مجموعة خوادم هو في موضع آخر: أين نجد Alpine دون أن نكون قد اخترناه؟ صورة حاوية تضم sshd لأغراض الصيانة، أو جهاز شبكي، أو موجّه يعمل بنظام OpenWrt، أو صورة بُنيت بـBuildroot أو Yocto: كلها قد تقوم على musl بحسب طريقة بنائها. وعلى خادم افتراضي بنظام Debian أو Ubuntu، يأتي التعرض من حاوية Alpine فيها sshd تشغّلها عليه، لا من النظام المضيف.
يكفي للجرد أمران لكل جهاز: يبيّن ls /lib/ld-musl* هل يستخدم النظام musl، ويبيّن ps aux | grep sshd هل تعمل خدمة SSH. نفّذهما كذلك داخل حاوياتك، فصورة أُعيد بناؤها العام الماضي قد تضم الحزمة القديمة.
تحقق من تعرضك ثم أصلح
تأكد من أن النظام يعمل بـmusl
نفّذ
ls /lib/ld-musl*أوldd --version 2>&1 | head -1. على Alpine يذكر الجواب musl. وعلى glibc لا شيء يلزم فعله بشأن هذه الثغرة.اعرف إصدار OpenSSH ونسخة PAM
يعرض
apk info -vv | grep '^openssh'الحزم المثبّتة. دوّن هلopenssh-server-pamموجودة، ثم افحصUsePAMفي/etc/ssh/sshd_config.اقرأ الإعداد المطبَّق فعليًا
يعرض
sshd -T | grep -i -E 'passwordauthentication|usepam|permitrootlogin'القيم الفعلية، بما فيها قيم كتلMatchوالملفات المضمَّنة. وسطر مقروء من الملف لا يغني عن هذا الفحص.أحصِ الحسابات ذات `*` والحسابات ذات كلمة المرور الفعلية
يعطي
awk -F: '$2=="*" {print $1}' /etc/shadowالحسابات التي لا كلمة مرور لها، ويعطيawk -F: '$2 ~ /^\$[56]\$/ {print $1}' /etc/shadowالحسابات التي لها تجزئة. إذا لم تكن القائمتان فارغتين فالشرطان 4 و5 متحققان.حدّث الحزمة
يثبّت
apk upgrade -U -aالإصدار المصحَّح. نشرت Alpine حزمًا مصحَّحة لجميع فروعها، حتى 3.16، بما فيها الفروع التي لم تعد مدعومة.أعد تشغيل الخدمة وإلا فلا شيء مُصلَح
نفّذ
rc-service sshd restart. تحديث الحزمة لا يستبدل الخدمة العاملة: ما دامت لم تُعد تشغيلها فإن الشيفرة القديمة هي التي تجيب. أبقِ جلسة مفتوحة أثناء إعادة التشغيل، واختبر اتصالًا ثانيًا قبل إغلاقها.تحقق من النتيجة
أعد قراءة
apk info -vv | grep '^openssh'، ثمsshd -T | grep -i passwordauthentication. بعد ذلك افتح اتصالًا بالمفتاح من جهاز آخر للتأكد من أن الوصول يعمل.أعد بناء الصور
لا تُصلَح صورة حاوية أو صورة جهاز افتراضي في مكانها: أعد بناءها من قاعدة مصحَّحة ثم أعد نشرها. دوّن تاريخ التصحيح في ملف البيئة.
الحزم المصحَّحة بحسب فرع Alpine
مرّر الجدول أفقيًا
| الفرع | حزمة openssh المصحَّحة | إصدار الفرع |
|---|---|---|
| edge | 10.6_p2-r0 | — |
| 3.24 | 10.3_p1-r2 | 3.24.4 |
| 3.23 | 10.2_p1-r1 | 3.23.8 |
| 3.22 | 10.0_p1-r11 | 3.22.8 |
| 3.21 | 9.9_p2-r1 | 3.21.10 |
| 3.20 والأقدم (حتى 3.16) | 9.7_p1-r6 (3.20) ؛ 9.0_p1-r6 (3.16) | فروع خارج الدعم |
ابحث عن آثار قبل أن تستنتج أن كل شيء سليم
التصحيح يزيل الثغرة، لكنه لا يمحو ما فعله مهاجم قبله. توصي نشرة Alpine بالبحث، في /var/log/messages، عن أسطر Accepted password for المتعلقة بحسابات يفترض ألا تكون لها كلمة مرور: alpine أو root أو مستخدم مخصص للدخول بالمفتاح. سطر كهذا مؤشر قوي، لأن هذه الحسابات لا ينبغي أن تدخل بكلمة مرور أبدًا.
وبالنسبة إلى الحسابات التي تظهر، افحص بعد ذلك استخدام doas والمستخدمين المنشأين حديثًا والملفات المعدَّلة ومحتوى كل ملف authorized_keys. ولا تترك النشرة شكًا في المسلك الواجب: إذا تعذر استبعاد أي اتصال، فعامل الجهاز على أنه مخترَق، وأعد بناءه، وجدّد الأسرار التي كان يحتويها. وفي صور السحابة الرسمية يكون الخطر أعلى: يملك المستخدم alpine فيها doas دون كلمة مرور، مما يتيح الحصول على صلاحيات root بعد الدخول.
لا تستطيع التحديث الآن؟ عطّل المصادقة بكلمة المرور، بعد التأكد من أن الاتصال بالمفتاح يعمل، مع إبقاء الجلسة الحالية مفتوحة. تقترح Alpine ملفًا في /etc/ssh/sshd_config.d/ يحتوي PasswordAuthentication no (يُقرأ هذا المجلد افتراضيًا منذ الإصدار 3.19)، بشرط ألا يبقى أي سطر PasswordAuthentication yes داخل كتلة Match. اختم بـsshd -t ثم إعادة تشغيل، ثم sshd -T | grep -i passwordauthentication الذي يجب أن يعرض passwordauthentication no. وللتراجع، احذف هذا الملف.
استكشاف الأخطاء: ما قد تراه عند تطبيق التصحيح
الرسائل التالية صادرة عن OpenSSH؛ تظهر في جهة العميل داخل الطرفية، وفي جهة الخادم داخل سجل الخدمة.
الرسائل وعلاجها
Permission denied (publickey).— بعد تعطيل كلمات المرور لا يُقبل مفتاحك. أبقِ الجلسة مفتوحة، وافحص~/.ssh/authorized_keysللحساب (الصلاحيات600والمجلد700)، ثم أعد قراءةsshd -T | grep -i pubkeyauthentication. لا تغلق الجلسة الأصلية قبل أن يكون لديك اتصال ثانٍ يعمل.Bad configuration optionمتبوعة باسم، مع رقم سطر من/etc/ssh/sshd_config— خطأ في الكتابة داخل الملف أو داخل الملف المضمَّن. يكشفهsshd -tقبل إعادة التشغيل: لا تعد التشغيل أبدًا دون هذا الفحص.sshd: no hostkeys available -- exiting.— مفاتيح المضيف غائبة، مثلًا في صورة لم تُولَّد فيها. ولّدها بـssh-keygen -Aثم أعد تشغيل الخدمة.- ما زالت الخدمة تجيب بالإصدار القديم — حدّثت الحزمة دون إعادة التشغيل. نفّذ
rc-service sshd restartثم أعد قراءة الإصدار المعلن عند الاتصال.
ما تقوله هذه الثغرة عن مجموعة خوادمك
لا تنشأ عن ممارسة سيئة لافتة: حساب بلا كلمة مرور، وآخر بكلمة مرور، وقيمة افتراضية. كل من هذه الخيارات شائع، ومزجها على نظام قليل الاستخدام هو ما يصنع التعرض. والجواب الدائم هو نفسه ما قبل الثغرة: على كل خادم يمكن بلوغه من الإنترنت، صادِق بالمفتاح، وعطّل كلمات المرور، واعرف أي الصور وأي الحاويات تضم sshd.
إذا كنت قد شددت وصولك من قبل، فهذا التنبيه يُعالج في عشر دقائق لكل جهاز. وإلا فهو فرصة لفعل ذلك: الإجراء الكامل موصوف في دليلنا لأول وصول عبر SSH، وتحديث OpenSSH 10.6 دون قطع الوصول موصوف في المقال المخصص لذلك الإصدار. يمنحك VPS من ServOrbit وصول root واختيار النظام، مما يترك لك التحكم في هذه الإعدادات.
