تشخيص أعطال تسجيل الدخول إلى SLES PAM دون فقدان الوصول إلى حسابك

لا تشير رسالة "فشل مصادقة PAM" إلى حل واحد شامل. حدد أولًا الخدمة والمستخدمين الذين فشلوا، ثم تحقق من سجل النظام في الوقت المطابق. في نظام SUSE Linux Enterprise Server (SLES)، أصلح مشكلة PAM العامة المؤكدة pam-config، ولا تُغير ملف خدمة مُحددة إلا إذا كان نظامها الداخلي معيبًا. أبقِ جلسة المستخدم الجذر أو جلسة الإدارة مفتوحة أثناء الاختبار؛ فقد يؤدي خلل في نظام PAM إلى منع تسجيلات الدخول الجديدة عبر SSH ووحدة التحكم.

يصف دليل الأمان والتحصين الحالي لنظام SLES 15 SP7 نظام إدارة الوصول المتميز (PAM) بأنه مجموعة من وحدات المصادقة والحساب وكلمة المرور والجلسة. هذا التمييز مهم: فقد تجتاز كلمة المرور الصحيحة هذه authالمرحلة، ومع ذلك يتم رفضها لاحقًا بواسطة سياسة الحساب أو قاعدة خاصة بالخدمة. ولا يمكن لرسالة الخطأ العامة وحدها تحديد المرحلة التي فشلت.

ما الذي يثبته الخطأ - وما الذي لا يثبته؟

تتوسط PAM بين تطبيق، مثل sshdتسجيل الدخول إلى وحدة التحكم، وطرق المصادقة المُهيأة. لكل خدمة مُهيأة لـ PAM ملفٌ ضمن /etc/pam.d/. قد يتضمن ملف الخدمة ملفات SLES الشائعة مثل common-authو common-account، لذا فإنّ عطلًا يقتصر على SSH قد يكون له سبب مختلف عن الأعطال التي تحدث في جميع طرق تسجيل الدخول.

تم التحقق: تتضمن حزمة SSH الموثقة من SUSE pam_nologin.soملفات PAM شائعة. في حال /etc/nologinوجودها، تمنع الوحدة الموثقة تسجيل دخول المستخدمين غير المستخدم الجذر. يعتمد ذلك على السياق: يمكن للقواعد المُعدّلة محليًا وخدمات الدليل ووحدات المصادقة متعددة العوامل الخارجية إضافة فحوصات إضافية. لا يُثبت من الرسالة وحدها ما إذا كانت كلمة المرور خاطئة، أو أن ملفات PAM تالفة، أو أن الحساب مُقفل. ابدأ بالخدمة المتأثرة وسجلها بدلًا من استبدال الحزمة.

ما هو مسار تسجيل الدخول الذي يفشل؟

قم بإعادة إنتاج الخطأ مرة واحدة وسجّل الوقت واسم المستخدم والطريقة: SSH، أو وحدة التحكم النصية المحلية، أو تسجيل الدخول الرسومي، sudoأو su. إذا تمكنت من تسجيل الدخول كمسؤول، فافحص رسائل النظام الأخيرة:

sudo journalctl -e

يوصي دليل استكشاف أخطاء SLES من SUSE تحديدًا بفحص سجل النظام بحثًا عن أخطاء تسجيل الدخول وPAM. ابحث في وقت المحاولة المحدد عن اسم الوحدة أو السبب، مثل رفض الحساب، أو عدم توفر خدمة الدليل، أو فقدان الوحدة، أو خطأ في الملف/الأذونات. لا تشارك السجلات علنًا دون إزالة أسماء المستخدمين، وأسماء المضيفين، والعناوين، وغيرها من التفاصيل الحساسة.

يتم تجهيز طرفية الجذر لفحص إدخالات سجل النظام الحديثة باستخدام journalctl -e.
استخدم سجل النظام حول وقت فشل تسجيل الدخول للعثور على رسائل PAM ورسائل عملية تسجيل الدخول.

إذا كان الاتصال عبر SSH هو الوحيد الذي يفشل، فافحص سجل برنامج SSH الخفي:

sudo journalctl -u sshd
يتم إعداد طرفية الجذر لقراءة سجل برنامج SSH daemon باستخدام الأمر journalctl -u sshd.
تحقق من سجل sshd عندما يحدث الفشل فقط أثناء مصادقة SSH.

ثم قارن مسارات الوصول. إذا تمكن المستخدم من المصادقة على وحدة التحكم المحلية ولكن ليس عبر SSH، فركز على /etc/pam.d/sshdسياسة الوصول إلى SSH أو وحدة نمطية خاصة بـ SSH. إذا رفضت خدمات متعددة نفس المستخدمين المحليين، فافحص ملفاتهم المشتركة common-*. إذا فشل مستخدم واحد فقط، فتحقق من حالة الحساب وكلمة المرور قبل تغيير المصادقة على مستوى النظام.

هل هذا حساب محلي أم هوية شبكة؟

بالنسبة للمستخدم المحلي، تحقق أولاً من اسم المستخدم، وتخطيط لوحة المفاتيح، ومفتاح Caps Lock. إذا لزم إعادة تعيين بيانات الاعتماد، فاستخدم أداة كلمات المرور المعتمدة من قِبل المسؤول، مثل YaST لإدارة المستخدمين والمجموعات، بدلاً من التعديل /etc/shadowاليدوي. إذا مُنع جميع المستخدمين غير الجذر من الوصول عبر SSH، فتحقق من وجود ملف صيانة مُخطط له /etc/nologinقبل تغيير PAM؛ قم بإزالته فقط إذا تأكدت من أن كتلة الصيانة قديمة وأنك مُصرّح لك بذلك.

بالنسبة لمستخدمي LDAP أو Active Directory أو أي دليل آخر، فإن وجود كلمة مرور صحيحة على خادم آخر لا يثبت قدرة مضيف SLES هذا على الوصول إلى موفر الهوية. تُشير SUSE إلى مشاكل الشبكة ونظام أسماء النطاقات (DNS)، وانحراف ساعة Kerberos، وقواعد PAM غير المُهيأة بشكل صحيح، وسياسة الوصول إلى المضيف، وعدم توفر أدلة المستخدمين الرئيسية، كأسباب محتملة. اختبر ما إذا كان بإمكان مستخدم نطاق آخر تسجيل الدخول، وما إذا كان بإمكان المستخدم المتأثر تسجيل الدخول إلى مضيف مختلف. ثم تحقق من خدمة الهوية المُهيأة واتصال الخادم.

عندما يستخدم المضيف SSSD، تحقق من الخدمة وما إذا كان PAM مُهيأً لاستخدامها:

systemctl status sssd
sudo pam-config --query --sss
يعرض طرفية أوامر استعلام تكوين PAM SSSD للقراءة فقط وأوامر حالة خدمة SSSD.
تحقق مما إذا كان SSSD مضمنًا في PAM ويعمل عندما يتعذر على المستخدمين المدعومين بالمجال المصادقة.

يمكن لـ SSSD تخزين معلومات المستخدم مؤقتًا، وقد يسمح بالمصادقة حتى في حال تعذر الوصول إلى الدليل مؤقتًا، ولكن هذا السلوك يعتمد على إعداداته وبيانات الاعتماد المخزنة مؤقتًا. لذا، فإن وجود بيانات مخزنة قديمة أو مفقودة هو أحد الاحتمالات، وليس نتيجة حتمية. تحقق من نظام أسماء النطاقات (DNS)، ومزامنة الوقت لبروتوكول Kerberos، وإمكانية الوصول إلى الدليل، وسجلات SSSD قبل مسح أي ذاكرة تخزين مؤقتة أو تغيير أي وحدة. إذا أبلغ موفر الهوية عن "قفل الحساب" أو "تعطيل الحساب"، فاطلب من مسؤول الدليل التحقق من سياسة ذلك الحساب؛ إذ أن PAM يُبلغ عن القرار، وليس بالضرورة أن يكون هو من يُنشئه.

كيف يمكنك إصلاح مشكلة مؤكدة في تكوين PAM؟

افحص الملف الخاص بالخدمة والقواعد المشتركة التي يتضمنها:

sudo grep -nE '^(auth|account|password|session)' /etc/pam.d/sshd
sudo pam-config --query --sss
يقوم أمر طرفي بفحص إدخالات المصادقة والحساب وكلمة المرور والجلسة في ملف خدمة sshd PAM.
راجع حزمة PAM الخاصة بالخدمة لـ sshd قبل تغيير قواعد المصادقة الشائعة.

في نظام SLES، pam-configيتم الاحتفاظ بالملفات العامة ضمن مجلد معين /etc/pam.d/common-*؛ أما ملفات الخدمات الفردية، مثل تلك /etc/pam.d/sshdالموجودة في مجلد آخر، فتُحفظ بشكل منفصل. لا تقم بتعديل الملفات العامة المُنشأة يدويًا إلا إذا قمتَ بتعطيلها عمدًا pam-config. إذا تأكدتَ من أن هذا المضيف مُصمم لاستخدام SSSD وأن قواعد PAM الخاصة به مفقودة، فراجع وثائق SUSE sudo pam-config --add --sssلإضافتها. استخدمه فقط بعد التأكد من أن SSSD مُهيأ ويعمل، ثم اختبر تسجيل دخول جديد بينما تبقى جلسة الإدارة الحالية مفتوحة.

من المفاهيم الخاطئة الشائعة، وإن كانت محفوفة بالمخاطر، أن هذا pam-config --createالأمر مجرد عملية إصلاح غير ضارة. توضح SUSE أنه يُنشئ إعدادات مصادقة Unix أساسية ويستبدل الملفات الموجودة مسبقًا والتي لا يديرها، مع الاحتفاظ بنسخ احتياطية. قد يؤدي ذلك إلى إزالة المصادقة متعددة العوامل المخصصة أو سلوك مصادقة الدليل. لا تستخدمه كخطوة استرداد عامة. في حالة وجود خطأ إملائي في ملف الخدمة، استعد إعدادات تلك الخدمة السليمة والمناسبة للإصدار من نسخة احتياطية موثوقة، أو غيّر السطر المعيب المحدد ضمن إجراءات التغيير المعتمدة في مؤسستك.

كيف يمكنك التأكد من إتمام عملية الإصلاح؟

اترك جلسة المستخدم الجذر أو المسؤول الأصلية مفتوحة. ابدأ جلسة ثانية عبر نفس الخدمة التي فشلت - مثل اتصال SSH جديد - واختبر الحساب المتأثر. تأكد من أن سجل النظام لم يعد يسجل نفس رفض PAM وأن طريقة مصادقة أخرى مُهيأة لا تزال تعمل. إذا استمر الفشل، فاحفظ الطابع الزمني الدقيق، والخدمة، واسم وحدة PAM، وسطور السجل ذات الصلة بعد تنقيحها؛ فهذه التفاصيل أكثر فائدة من رسالة "فشل المصادقة" العامة.

المراجع الرسمية

اترك تعليقاً

تشخيص أعطال تسجيل الدخول إلى SLES PAM دون فقدان الوصول إلى حسابك

تشخيص أعطال تسجيل الدخول إلى SLES PAM دون فقدان الوصول إلى حسابك

تتبع فشل PAM إلى الخدمة أو سياسة الحساب أو موفر الهوية، ثم قم بإصلاح تكوين SLES الصحيح مع الحفاظ على جلسة مسؤول عاملة.

أتمتة عمليات النسخ الاحتياطي المتسقة لـ Nextcloud باستخدام Restic و Cron

أتمتة عمليات النسخ الاحتياطي المتسقة لـ Nextcloud باستخدام Restic و Cron

قم بعمل نسخ احتياطية لملفات Nextcloud و MariaDB معًا، وجدول لقطات Restic المشفرة باستخدام cron، وتحقق من الاستعادة دون المخاطرة بالخادم المباشر.

تشغيل خادم أوبونتو في وضع الطوارئ: دليل إنقاذ خطوة بخطوة

تشغيل خادم أوبونتو في وضع الطوارئ: دليل إنقاذ خطوة بخطوة

قم بتشخيص وضع الطوارئ في خادم أوبونتو بأمان. اقرأ سجلات بدء التشغيل، وتحقق من مجلدات الجذر و fstab، وأصلح الوحدة المعطلة، وتعامل مع أخطاء نظام الملفات، وتحقق من إعادة التشغيل النظيفة.

نسخ احتياطي واستعادة صندوق بريد Zimbra CE باستخدام ملفات TGZ

نسخ احتياطي واستعادة صندوق بريد Zimbra CE باستخدام ملفات TGZ

قم بتصدير صندوق بريد فردي من إصدار Zimbra Community Edition، وتحقق من صحة نسخة TGZ الاحتياطية الخاصة به، واستعد العناصر المفقودة دون الكتابة فوق البريد الموجود.

السماح للمستخدمين المعتمدين بإنشاء غرف Jitsi باستخدام تسجيل الدخول عبر Keycloak

السماح للمستخدمين المعتمدين بإنشاء غرف Jitsi باستخدام تسجيل الدخول عبر Keycloak

السماح فقط للحسابات المعتمدة ببدء غرف Jitsi Meet باستخدام Keycloak ومصادقة الرمز المميز، مع إبقاء إمكانية انضمام الضيوف متاحة عند الحاجة.

مزامنة مستخدمي Active Directory مع ONLYOFFICE DocSpace عبر LDAP

مزامنة مستخدمي Active Directory مع ONLYOFFICE DocSpace عبر LDAP

قم بتوصيل ONLYOFFICE DocSpace بـ Active Directory أو OpenLDAP، واستورد المستخدمين والمجموعات بأمان، وقم بتعيين حقول الحساب، وجدول مزامنة موثوقة.

إضافة الخطوط إلى خادم مستندات ONLYOFFICE: دوكر مقابل لينكس

إضافة الخطوط إلى خادم مستندات ONLYOFFICE: دوكر مقابل لينكس

قم بتثبيت الخطوط المخصصة في خادم مستندات ONLYOFFICE، وقارن عمليات تحميل Docker الدائمة مع النسخ المباشرة، وأعد بناء قائمة الخطوط، وتحقق من النتيجة.

دبيان 12 على خادم افتراضي خاص ذي ذاكرة وصول عشوائي منخفضة: كيفية تقليل أعطال نفاد الذاكرة في MySQL

دبيان 12 على خادم افتراضي خاص ذي ذاكرة وصول عشوائي منخفضة: كيفية تقليل أعطال نفاد الذاكرة في MySQL

تشخيص عمليات إيقاف MySQL بسبب نفاد الذاكرة على Debian 12، والتحقق من حدود ذاكرة VPS، وتكوين التبديل، وضبط ذاكرة قاعدة البيانات والتزامن دون تقديم حل شامل.

تثبيت وتوقيع وحدات نواة مخصصة على نظام التشغيل SLES 15 Secure Boot

تثبيت وتوقيع وحدات نواة مخصصة على نظام التشغيل SLES 15 Secure Boot

قم بتحميل وحدة نواة SLES 15 مخصصة دون تعطيل خاصية التمهيد الآمن. طابق النواة قيد التشغيل، ووقّع ملف .ko، وسجّل مفتاح MOK، وتحقق من التحميل.

ضع مستندات ONLYOFFICE خلف HAProxy دون تعطيل التحرير

ضع مستندات ONLYOFFICE خلف HAProxy دون تعطيل التحرير

قم بتكوين HAProxy HTTPS، وإعادة توجيه الرؤوس، ومهلات WebSocket، وفحوصات السلامة لـ ONLYOFFICE Docs، ثم تحقق من التحرير والحفظ.