วินิจฉัยปัญหาการเข้าสู่ระบบ SLES PAM ล้มเหลวโดยไม่ต้องล็อกตัวเองออกจากระบบ

ข้อความ “PAM authentication failure” ไม่ได้ระบุวิธีแก้ไขแบบเดียวที่ใช้ได้กับทุกกรณี ขั้นแรกให้ระบุว่าบริการและผู้ใช้ใดที่ล้มเหลว จากนั้นตรวจสอบบันทึกเหตุการณ์ในช่วงเวลาที่ตรงกัน บน SUSE Linux Enterprise Server (SLES) ให้แก้ไขปัญหา PAM ระดับโลกที่ได้รับการยืนยันแล้วผ่านทางpam-configและแก้ไขไฟล์บริการแต่ละไฟล์เฉพาะเมื่อสแต็กของบริการนั้นผิดพลาดเท่านั้น ควรเปิดเซสชัน root หรือผู้ดูแลระบบที่ใช้งานได้ไว้ในขณะทดสอบ เนื่องจากสแต็ก 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มีอยู่ โมดูลที่ระบุไว้ในเอกสารจะปฏิเสธการเข้าสู่ระบบสำหรับผู้ใช้ที่ไม่ใช่ root ขึ้นอยู่กับบริบท:กฎที่แก้ไขในเครื่อง บริการไดเร็กทอรี และโมดูล MFA ของบุคคลที่สามสามารถเพิ่มการตรวจสอบเพิ่มเติมได้ไม่สามารถระบุได้จากข้อความเพียงอย่างเดียว:ว่ารหัสผ่านผิด ว่าไฟล์ PAM เสียหาย หรือว่าบัญชีถูกล็อก เริ่มต้นด้วยบริการที่ได้รับผลกระทบและบันทึกของบริการนั้นแทนที่จะเปลี่ยนชุดคำสั่งทั้งหมด

ช่องทางการเข้าสู่ระบบใดที่ใช้งานไม่ได้?

จำลองข้อผิดพลาดนี้หนึ่งครั้งและจดบันทึกเวลา ชื่อผู้ใช้ และวิธีการ: SSH, คอนโซลข้อความในเครื่อง, การเข้าสู่ระบบแบบกราฟิกsudoหรือsuหากคุณสามารถเข้าสู่ระบบในฐานะผู้ดูแลระบบได้ โปรดตรวจสอบข้อความระบบล่าสุด:

sudo journalctl -e

คู่มือการแก้ไขปัญหา SLES ของ SUSE แนะนำเป็นพิเศษให้ตรวจสอบบันทึก (journal) สำหรับข้อผิดพลาดในการเข้าสู่ระบบและ PAM ให้มองหาชื่อโมดูลหรือเหตุผลในช่วงเวลาที่พยายามเข้าสู่ระบบ เช่น บัญชีถูกปฏิเสธ บริการไดเร็กทอรีไม่พร้อมใช้งาน โมดูลหายไป หรือข้อผิดพลาดเกี่ยวกับไฟล์/สิทธิ์การเข้าถึง ห้ามเผยแพร่บันทึกต่อสาธารณะโดยไม่ลบชื่อผู้ใช้ ชื่อโฮสต์ ที่อยู่ และรายละเอียดที่ละเอียดอ่อนอื่นๆ ออกก่อน

หากการเชื่อมต่อ SSH ล้มเหลวเพียงอย่างเดียว ให้ตรวจสอบบันทึกการทำงานของ SSH daemon:

sudo journalctl -u sshd

จากนั้นเปรียบเทียบเส้นทางการเข้าถึง หากผู้ใช้สามารถตรวจสอบสิทธิ์ได้ที่คอนโซลภายในเครื่อง แต่ไม่สามารถตรวจสอบสิทธิ์ผ่าน SSH ได้ ให้เน้นที่/etc/pam.d/sshdนโยบายการเข้าถึง SSH หรือโมดูลเฉพาะของ SSH หากบริการหลายแห่งปฏิเสธผู้ใช้ภายในเครื่องเดียวกัน ให้ตรวจสอบcommon-*ไฟล์ที่แชร์ หากมีผู้ใช้เพียงรายเดียวที่ล้มเหลว ให้ตรวจสอบสถานะบัญชีและรหัสผ่านก่อนที่จะเปลี่ยนการตรวจสอบสิทธิ์ทั่วทั้งระบบ

นี่เป็นบัญชีภายในเครื่องหรือบัญชีเครือข่ายครับ/คะ?

สำหรับผู้ใช้ภายในเครื่อง ให้ตรวจสอบชื่อผู้ใช้ รูปแบบแป้นพิมพ์ และปุ่ม Caps Lock ก่อน หากจำเป็นต้องรีเซ็ตข้อมูลประจำตัว ให้ใช้เครื่องมือจัดการรหัสผ่านที่ผู้ดูแลระบบอนุมัติ เช่น YaST User and Group Management แทนการแก้ไข/etc/shadowด้วยตนเอง หากผู้ใช้ที่ไม่ใช่ root ทุกคนถูกปฏิเสธการเข้าถึงผ่าน 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 รายงานการตัดสินใจ ไม่ได้หมายความว่าเป็นผู้สร้างการตัดสินใจนั้น

คุณควรแก้ไขปัญหาการกำหนดค่า 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 ของ SSSD หายไป เอกสารของ SUSE มีวิธีsudo pam-config --add --sssการเพิ่มกฎเหล่านั้น ใช้งานหลังจากยืนยันแล้วว่า SSSD ได้รับการกำหนดค่าและทำงานอยู่ จากนั้นทดสอบการเข้าสู่ระบบใหม่ในขณะที่เซสชันการดูแลระบบที่ใช้งานอยู่ยังคงเปิดอยู่

ความเข้าใจผิดที่พบบ่อยแต่เสี่ยงคือ การคิดว่าpam-config --createคำสั่งนี้เป็นคำสั่งซ่อมแซมที่ไม่เป็นอันตราย SUSE ระบุว่าคำสั่งนี้จะสร้างการกำหนดค่าการตรวจสอบสิทธิ์ Unix พื้นฐานและเขียนทับไฟล์ที่มีอยู่เดิมซึ่งไม่ใช่ไฟล์ที่ SUSE จัดการ โดยจะเก็บสำเนาสำรองไว้ ซึ่งอาจลบการตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA) หรือการตรวจสอบสิทธิ์ตามไดเร็กทอรีที่กำหนดเองได้ อย่าใช้คำสั่งนี้เป็นขั้นตอนการกู้คืนทั่วไป สำหรับข้อผิดพลาดในการพิมพ์ในไฟล์บริการ ให้กู้คืนการกำหนดค่าที่ถูกต้องและเหมาะสมกับเวอร์ชันของบริการนั้นจากข้อมูลสำรองที่เชื่อถือได้ หรือเปลี่ยนบรรทัดที่ผิดพลาดเฉพาะนั้นตามกระบวนการเปลี่ยนแปลงขององค์กรของคุณ

คุณจะยืนยันการซ่อมแซมได้อย่างไร?

ปล่อยให้เซสชัน root หรือ administrator เดิมเปิดอยู่ เริ่มเซสชันที่สองผ่านบริการเดียวกันกับที่ล้มเหลว เช่น การเชื่อมต่อ SSH ใหม่ และทดสอบบัญชีที่ได้รับผลกระทบ ตรวจสอบให้แน่ใจว่าบันทึกไม่บันทึกการปฏิเสธ PAM เดิมอีกต่อไป และวิธีการตรวจสอบสิทธิ์ที่กำหนดค่าไว้อื่นยังคงใช้งานได้ หากความล้มเหลวยังคงเกิดขึ้น ให้บันทึกเวลาที่เกิดเหตุการณ์ บริการ ชื่อโมดูล PAM และบรรทัดบันทึกที่เกี่ยวข้องที่ผ่านการกรองแล้ว รายละเอียดเหล่านั้นมีประโยชน์มากกว่าข้อความทั่วไปว่า "การตรวจสอบสิทธิ์ล้มเหลว"

ข้อมูลอ้างอิงอย่างเป็นทางการ

• คู่มือการดูแลระบบ SUSE SLES 15 SP7: ปัญหาทั่วไปและวิธีแก้ไข — การแก้ไขปัญหาการเข้าสู่ระบบทั้งแบบภายในเครื่องและผ่านเครือข่าย
• คู่มือความปลอดภัยและการเสริมความแข็งแกร่งของ SUSE SLES 15 SP7: การตรวจสอบสิทธิ์ด้วย PAM — ขั้นตอน PAM, สแต็ก SSH และpam-config.
• SUSE SLES 15 SP7: การตั้งค่าไคลเอ็นต์การตรวจสอบสิทธิ์โดยใช้ YaST — สถานะ SSSD และพฤติกรรมแคช
• SUSE SLES 15 SP7: การรักษาความปลอดภัยการทำงานของเครือข่ายด้วย OpenSSH — การดูข้อความบันทึกของ sshd