تشخيص أعطال تسجيل الدخول إلى SLES PAM دون فقدان الوصول إلى حسابك
تتبع فشل PAM إلى الخدمة أو سياسة الحساب أو موفر الهوية، ثم قم بإصلاح تكوين SLES الصحيح مع الحفاظ على جلسة مسؤول عاملة.
لا تشير رسالة "فشل مصادقة 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. ابحث في وقت المحاولة المحدد عن اسم الوحدة أو السبب، مثل رفض الحساب، أو عدم توفر خدمة الدليل، أو فقدان الوحدة، أو خطأ في الملف/الأذونات. لا تشارك السجلات علنًا دون إزالة أسماء المستخدمين، وأسماء المضيفين، والعناوين، وغيرها من التفاصيل الحساسة.

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

ثم قارن مسارات الوصول. إذا تمكن المستخدم من المصادقة على وحدة التحكم المحلية ولكن ليس عبر 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

يمكن لـ SSSD تخزين معلومات المستخدم مؤقتًا، وقد يسمح بالمصادقة حتى في حال تعذر الوصول إلى الدليل مؤقتًا، ولكن هذا السلوك يعتمد على إعداداته وبيانات الاعتماد المخزنة مؤقتًا. لذا، فإن وجود بيانات مخزنة قديمة أو مفقودة هو أحد الاحتمالات، وليس نتيجة حتمية. تحقق من نظام أسماء النطاقات (DNS)، ومزامنة الوقت لبروتوكول Kerberos، وإمكانية الوصول إلى الدليل، وسجلات SSSD قبل مسح أي ذاكرة تخزين مؤقتة أو تغيير أي وحدة. إذا أبلغ موفر الهوية عن "قفل الحساب" أو "تعطيل الحساب"، فاطلب من مسؤول الدليل التحقق من سياسة ذلك الحساب؛ إذ أن PAM يُبلغ عن القرار، وليس بالضرورة أن يكون هو من يُنشئه.
افحص الملف الخاص بالخدمة والقواعد المشتركة التي يتضمنها:
sudo grep -nE '^(auth|account|password|session)' /etc/pam.d/sshd
sudo pam-config --query --sss

في نظام 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، وسطور السجل ذات الصلة بعد تنقيحها؛ فهذه التفاصيل أكثر فائدة من رسالة "فشل المصادقة" العامة.
pam-config.تتبع فشل PAM إلى الخدمة أو سياسة الحساب أو موفر الهوية، ثم قم بإصلاح تكوين SLES الصحيح مع الحفاظ على جلسة مسؤول عاملة.
قم بعمل نسخ احتياطية لملفات Nextcloud و MariaDB معًا، وجدول لقطات Restic المشفرة باستخدام cron، وتحقق من الاستعادة دون المخاطرة بالخادم المباشر.
قم بتشخيص وضع الطوارئ في خادم أوبونتو بأمان. اقرأ سجلات بدء التشغيل، وتحقق من مجلدات الجذر و fstab، وأصلح الوحدة المعطلة، وتعامل مع أخطاء نظام الملفات، وتحقق من إعادة التشغيل النظيفة.
قم بتصدير صندوق بريد فردي من إصدار Zimbra Community Edition، وتحقق من صحة نسخة TGZ الاحتياطية الخاصة به، واستعد العناصر المفقودة دون الكتابة فوق البريد الموجود.
السماح فقط للحسابات المعتمدة ببدء غرف Jitsi Meet باستخدام Keycloak ومصادقة الرمز المميز، مع إبقاء إمكانية انضمام الضيوف متاحة عند الحاجة.
قم بتوصيل ONLYOFFICE DocSpace بـ Active Directory أو OpenLDAP، واستورد المستخدمين والمجموعات بأمان، وقم بتعيين حقول الحساب، وجدول مزامنة موثوقة.
قم بتثبيت الخطوط المخصصة في خادم مستندات ONLYOFFICE، وقارن عمليات تحميل Docker الدائمة مع النسخ المباشرة، وأعد بناء قائمة الخطوط، وتحقق من النتيجة.
تشخيص عمليات إيقاف MySQL بسبب نفاد الذاكرة على Debian 12، والتحقق من حدود ذاكرة VPS، وتكوين التبديل، وضبط ذاكرة قاعدة البيانات والتزامن دون تقديم حل شامل.
قم بتحميل وحدة نواة SLES 15 مخصصة دون تعطيل خاصية التمهيد الآمن. طابق النواة قيد التشغيل، ووقّع ملف .ko، وسجّل مفتاح MOK، وتحقق من التحميل.
قم بتكوين HAProxy HTTPS، وإعادة توجيه الرؤوس، ومهلات WebSocket، وفحوصات السلامة لـ ONLYOFFICE Docs، ثم تحقق من التحرير والحفظ.