เปิดการดีบัก PAM เป็น Syslog

ฉันเกลียด PAM ตั้งแต่มันเกิดขึ้น

ฉันจะเปิดการดีบัก PAM ใน Debian Squeeze ในระดับผู้ดูแลระบบได้อย่างไร

ฉันได้ตรวจสอบทุกทรัพยากรที่ฉันสามารถหาได้ Google manpages อะไรก็ตาม สิ่งเดียวที่ฉันยังไม่ได้ลองเลย (ฉันไม่กล้าพูดถึงฉันเกลียด PAM หรือเปล่า) กำลังขุดเข้าไปในแหล่งห้องสมุดของ PAM

ฉันพยายาม google หาทางออกไม่มีอะไร สิ่งที่ฉันพบ:

http://www.bitbull.ch/wiki/index.php/Pam_debugging_funktion ( /etc/pam_debug) และ http://nixdoc.net/man-pages/HP-UX/man4/pam.conf.4.html ( debugตัวเลือกสำหรับรายการ PAM ใน/etc/pam.d/)

ไม่ไม่ทำงาน ไม่มีเอาต์พุต PAM ไม่มีอะไรเงียบอย่างแน่นอน

ในขณะที่ค้นหาวิธีแก้ปัญหาฉันยังติดตามลิงก์ไปยัง Pam ซึ่งเป็นสถานีบริการน้ำมันที่นี่ในเยอรมนี บางทีอาจจะมีผู้ชมหลายพันคนในที่หลบซ่อนเบาะแส แต่ยิงฉันฉันจะตายก่อนที่ฉันจะค้นพบ

ส่วนที่เหลือคือ FYI:

ฉันมีปัญหาอะไร

หลังจากอัปเกรดเป็น Debian Squeeze มีบางอย่างแปลก ๆ (ก็เฮ้มันเคยครั้งหนึ่งเอ่อสิ่งที่ถูกต้องเหนือ Etch .. อ่าใช่วู้ดดี้) ดังนั้นมันอาจไม่ใช่ความผิดของ Debian เพียงแค่ติดตั้งนานเกินไป ฉันมีความประทับใจทันทีที่ต้องทำอะไรบางอย่างกับ PAM แต่ฉันไม่รู้จริงๆว่าเกิดอะไรขึ้น ฉันอยู่ในความมืดมิดเหลือเพียงลำพังไร้ประโยชน์เหมือนเด็กทารก YKWIM การเข้าสู่ระบบ SSH บางอย่างทำงานได้บางคนไม่ มันตลกดี ไม่มีเงื่อนงำในssh -vไม่มีเงื่อนงำใน/var/log/*ไม่มีอะไร เพียงแค่ "รับรองความถูกต้องสำเร็จ" หรือ "รับรองความถูกต้องล้มเหลว" บางครั้งผู้ใช้รายเดียวกันเข้าสู่ระบบสำเร็จในหนึ่งครั้งและล้มเหลวพร้อมกัน และไม่มีอะไรที่คุณจะได้รับ

หลังจากขุดทางเลือกอื่น ๆ ฉันก็สามารถหาคำตอบได้ มีnullokและnullok_secureเป็น Debian พิเศษ มีบางอย่างผิดพลาด/etc/securettyและขึ้นอยู่กับtty(ซึ่งค่อนข้างสุ่ม) การเข้าสู่ระบบถูกปฏิเสธหรือไม่ ดีจริงเหรอ!

การแก้ไขนั้นง่ายและทุกอย่างก็กลับมาดีอีกครั้ง

อย่างไรก็ตามเรื่องนี้ทำให้ฉันมีคำถามวิธีการแก้ปัญหาความยุ่งเหยิงดังกล่าวในอนาคต ไม่ใช่ครั้งแรกที่ PAM ผลักดันฉันให้คลั่ง ดังนั้นฉันต้องการเห็นทางออกสุดท้าย สุดท้ายใน "แก้ไข" ไม่ใช่ครั้งสุดท้ายใน "armageddon" ขอบคุณ

อืม BTW สิ่งนี้ทำให้ความเชื่อของฉันแข็งแกร่งขึ้นอีกว่ามันเป็นการดีที่จะเกลียด PAM ตั้งแต่มันเกิดขึ้น ฉันพูดถึงสิ่งที่ฉันทำหรือไม่?

สองสามสิ่งที่คุณต้องลอง:

คุณเปิดใช้งานการบันทึกข้อความดีบักใน syslog หรือไม่

cp /etc/syslog.conf /etc/syslog.conf.original
vi /etc/syslog.conf

เพิ่มบรรทัดต่อไปนี้:

*.debug     /var/log/debug.log

:wq!ทางออกด้วย

touch /var/log/debug.log
service syslog restart

คุณสามารถเปิดใช้งานการดีบักสำหรับโมดูลทั้งหมดดังนี้:

touch /etc/pam_debug

หรือคุณสามารถเปิดใช้งานการดีบักสำหรับโมดูลที่คุณสนใจโดยเพิ่ม "debug" ที่ส่วนท้ายของบรรทัดที่เกี่ยวข้อง/etc/pam.d/system-authหรือ/etc/pam.d/*ไฟล์อื่น ๆ:

login   auth    required    pam_unix.so debug

จากนั้นการดีบั๊กข้อความจะเริ่มปรากฏ/var/log/debug.logขึ้น หวังว่านี่จะช่วยคุณได้!

อย่างน้อยใน CentOS 6.4 /etc/pam_debugจะไม่ถูกใช้

หากมีการติดตั้งโมดูล pam_warn.so คุณสามารถรับเอาต์พุตการบันทึกด้วยวิธีนี้:

auth required pam_warn.so

success required pam_warn.so

ฯลฯ โมดูลนี้ทำให้มั่นใจได้ว่ามันจะไม่ยุ่งเกี่ยวกับกระบวนการตรวจสอบที่จุดใด ๆ แต่มันจะบันทึกสิ่งที่มีความหมายผ่าน syslog

ปรับปรุง

หลังจากตรวจสอบรหัสและทำการรวบรวมบางอย่างฉันพบว่า (1) เป็นไปได้ที่จะเปิดใช้งานโหมดแก้ไขข้อบกพร่องนี้ผ่านแหล่งที่มาและ (2) แพตช์ RHEL ทำให้คุณสมบัติใช้งานไม่ได้เกือบ (อย่างน้อยโมดูล pam_unix) และ (3) อาจจะดีกว่าที่จะแก้ไขรหัสต่อไป

เพื่อให้สิ่งนี้ใช้งานได้กับ RHEL คุณสามารถรับ Linux-PAM ... src.rpm (สำหรับรุ่น 1.1) และเปลี่ยนไฟล์ spec ดังต่อไปนี้:

• ค้นหาบรรทัดที่ขึ้นต้นด้วย

  % configure \

และหลังจากนั้นให้เพิ่ม --enable-debug \

• ลบบรรทัดหรือแสดงความคิดเห็นออกบรรทัด (เหนือบรรทัดก่อนหน้า) ที่เริ่มต้นด้วย% patch2

จากนั้นสร้างรอบต่อนาทีและติดตั้ง (ด้วยแรงเพื่อเขียนทับแพ็คเกจที่มีอยู่) ตอนนี้สร้างไฟล์ /var/run/pam-debug.log:

install -m 622 /dev/null /var/run/pam-debug.log

หากไฟล์ไม่มีอยู่ debug output จะถูกส่งไปยัง stderr

• การส่งออกไปยัง stderr นี้ในความคิดของฉันโง่และเป็นสิ่งที่ทำให้แพทช์ขัดแย้ง คุณสามารถเปลี่ยนพฤติกรรมดังกล่าวได้โดยไปที่ไฟล์libpam / include / security / _pam_macros.hและแทนที่ 4 บรรทัดของ

  logfile = stderr;

กับ

return;

ในการสร้างคุณจะได้รับคำเตือนเกี่ยวกับคำสั่งที่ไม่สามารถเข้าถึงได้ แต่สามารถเพิกเฉยได้ คุณสามารถทำการเปลี่ยนแปลงนี้ในสคริปต์ sed (และวางไว้ในส่วนการเตรียม% ของ RPM หลังแพทช์) ...

sed -i 's/logfile = stderr;$/return;/' libpam/include/security/_pam_macros.h

หากคุณทำแก้ไขเล็ก ๆ น้อย ๆ นี้คุณสามารถคืนค่า% patch2 ได้เนื่องจากมันควรจะทำงานได้อย่างถูกต้องอีกครั้ง

ฉันเพิ่งใช้เวลาหลายชั่วโมงพยายามหาวิธีเปิดใช้งานบันทึกการดีบักใน PAM บน CentOS 6.4 แม้ว่าคำถามนี้มีไว้สำหรับเดเบียน แต่ฉันจะยังคงจดบันทึกว่าจะทำอย่างไรกับ CentOS ด้วยความหวังว่าคนอื่นไม่จำเป็นต้องใส่ในเวลาที่ฉันมีอยู่แล้ว

เมื่อเปิดใช้งานแล้วการเปิดใช้งานการดีบักล็อกในpamแพ็คเกจ CentOS นั้นเรียบง่าย ความยากลำบากเกิดขึ้นจากข้อเท็จจริงที่ว่ามันเกี่ยวข้องกับการคอมไพล์ซ้ำของแพคเกจ ดังนั้นก่อนพบว่า SRPM (เช่นpam-1.1.1-13.el6.src.rpm) จากที่นี่ คนที่ไม่ทราบเกี่ยวกับการรวบรวมแพคเกจจาก SRPMS, สามารถดูขั้นตอนในการตั้งค่า RPM สร้างสภาพแวดล้อม

นี่คือขั้นตอนหลัก เปิดไฟล์ข้อมูลจำเพาะและเพิ่ม--enable-debugไปยัง%buildส่วนในการconfigureเรียกใช้ recompile! ติดตั้งแพคเกจที่สร้างขึ้นใหม่อีกครั้ง ในที่สุดสร้างไฟล์ที่บันทึกการแก้ปัญหาจะได้รับการเขียน

$ sudo touch /var/run/pam-debug.log

หากคุณไม่สร้างไฟล์บันทึกจำนวนมากจะถูกส่งไปที่เทอร์มินัลซึ่งอาจไม่มีประโยชน์มากนัก

Debian และ Ubuntu (และ distros อื่น ๆ ) มีไฟล์บันทึกพิเศษซึ่งบันทึก pam ทั้งหมดจะถูกบันทึก:

/var/log/auth.log

ฉันดิ้นรนกับปัญหาที่เกี่ยวข้องกับแพมเป็นเวลาครึ่งวันในที่สุดก็ค้นพบเกี่ยวกับไฟล์บันทึกนี้และช่วยตัวเองให้พ้นจากความวิกลจริต

นี่คือตัวอย่างเนื้อหาของไฟล์นี้เมื่อสิ่งต่าง ๆ ไม่เป็นไปตามแผนที่วางไว้

Jul 10 09:31:14 vagrant-ubuntu-trusty-64 pamtester: pam_userdb(vsftpd:auth): user_lookup: could not open database `/etc/vsftpd_users.db': No such file or directory
Jul 10 09:36:20 vagrant-ubuntu-trusty-64 sudo:  vagrant : TTY=pts/1 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/cat /var/log/auth.log

นี่คือลักษณะเมื่อใช้งานได้:

Jul 10 09:47:00 vagrant-ubuntu-trusty-64 sshd[5222]: pam_unix(sshd:session): session closed for user vagrant
Jul 10 09:50:58 vagrant-ubuntu-trusty-64 sshd[5584]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
Jul 10 09:50:58 vagrant-ubuntu-trusty-64 sshd[5584]: Accepted publickey for vagrant from 10.0.2.2 port 54652 ssh2: RSA dd:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6
Jul 10 09:50:58 vagrant-ubuntu-trusty-64 sshd[5584]: pam_unix(sshd:session): session opened for user vagrant by (uid=0)
Jul 10 09:51:13 vagrant-ubuntu-trusty-64 sudo:  vagrant : TTY=pts/1 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/cat /var/log/auth.log
Jul 10 09:51:13 vagrant-ubuntu-trusty-64 sudo: pam_unix(sudo:session): session opened for user root by vagrant(uid=0)
Jul 10 09:51:13 vagrant-ubuntu-trusty-64 sudo: pam_unix(sudo:session): session closed for user root
Jul 10 09:51:41 vagrant-ubuntu-trusty-64 pamtester: pam_userdb(vsftpd:auth): user 'foo' granted access
Jul 10 09:51:44 vagrant-ubuntu-trusty-64 sudo:  vagrant : TTY=pts/1 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/cat /var/log/auth.log
Jul 10 09:51:44 vagrant-ubuntu-trusty-64 sudo: pam_unix(sudo:session): session opened for user root by vagrant(uid=0)

โปรดทราบว่าไม่มีความเป็นไปได้อื่น ๆ สำหรับการเปิดใช้งานการบันทึก debug แพมสำหรับฉัน

มีบางอย่างผิดพลาดกับ / etc / securetty และขึ้นอยู่กับ tty (ซึ่งค่อนข้างสุ่ม) ล็อกอินถูกปฏิเสธหรือไม่ ดีจริงเหรอ!

คุณช่วยขยายความเล็กน้อยได้ไหม?

ตามmanpage ของ securetty :

the file contains the device names of terminal lines (one per line, without leading /dev/) on which root is allowed to login.

พฤติกรรมที่คุณอธิบายฟังดูค่อนข้างมากเช่น securetty นั้นทำงานได้ตามปกติ (สมมติว่าคุณกำลังเข้าสู่ระบบในฐานะรูท)

การเข้าสู่ระบบ SSH บางอย่างทำงานได้บางอย่างไม่ได้

ที่นี่เช่นกันอาจมีข้อ จำกัด ที่ไม่ใช่ PAM ดังนั้นจึงอาจช่วยให้เข้าใจถึง/etc/ssh/sshd_configลักษณะของคุณ

โดยเฉพาะอย่างยิ่งจากคำอธิบายของคุณ:

• หากคุณพยายามเข้าสู่ระบบในฐานะ root และล้มเหลวนั่นอาจเป็นเพราะบรรทัดนี้มีอยู่ในsshd_config:PermitRootLogin no
• ถ้าบางผู้ใช้ / กลุ่มการทำงานและอื่น ๆ ไม่ได้เป็นเหตุผลหนึ่งที่อาจจะใช้ในsshd_configการหรือAllowGroups AllowUsersบรรทัดตัวอย่างอาจมีลักษณะดังนี้: AllowGroups users admins

แน่นอนว่าเป็นไปได้ทั้งหมดที่ PAM เป็นส่วนหนึ่งของปัญหา แต่เสียง 'อาการ' หลักของคุณสำหรับฉันเหมือนพวกเขาสามารถอธิบายได้ด้วยวิธีการอื่น

Asket ... ฉันชอบโพสต์ของคุณจริง ๆ :) ฉันต่อสู้กับสิ่งนี้ในช่วง 15 ชั่วโมงที่ผ่านมา ... (ฉันอาจจะต้องพัก 30 นาที)

อย่างใดฉันได้มันทำงานโดยทำทุกสิ่งที่คุณทำซึ่งหมายความว่าฉันมี / etc / pam_debug และ debug ในรายการ pam แต่ในกรณีของฉันฉันกำลังดิ้นรนกับpam_mysqlฉันต้องใส่อีกverbose=1หลังจากdebugรายการแพมของฉัน:

mailsystem:~# cat /etc/pam.d/smtp

auth required pam_mysql.so debug sqllog=1 verbose=1 user=mail passwd=imverysecret host=127.0.0.1 db=mail table=mailbox usercolumn=username passwdcolumn=password crypt=1 logtable=log_auth logmsgcolumn=msg logusercolumn=user logpidcolumn=pid loghostcolumn=host logtimecolumn=time

account sufficient pam_mysql.so debug sqllog=1 verbose=1 user=mail passwd=imverysecret host=127.0.0.1 db=mail table=mailbox usercolumn=username passwdcolumn=password crypt=1 logtable=log_auth logmsgcolumn=msg logusercolumn=user logpidcolumn=pid loghostcolumn=host logtimecolumn=times

"sqllog" นั้นเป็นเพียงการเขียนบันทึกในฐานข้อมูล

ดังนั้นนี่อาจช่วยคุณได้เล็กน้อย

เราทุกคนเกลียด PAM โชคดี!