Bật gỡ lỗi PAM sang Syslog

Tôi ghét PAM kể từ khi nó xuất hiện.

Làm cách nào để bật gỡ lỗi PAM trong Debian Squeeze ở cấp quản trị viên?

Tôi đã kiểm tra mọi tài nguyên tôi có thể tìm thấy. Google, trang web, bất cứ điều gì. Điều duy nhất tôi chưa thử (đơn giản là tôi không dám, tôi có đề cập đến việc tôi ghét PAM không?) Đang đào sâu vào nguồn thư viện của PAM.

Tôi đã cố gắng để google cho một giải pháp, không có gì. Những gì tôi tìm thấy cho đến nay:

http://www.bitbull.ch/wiki/index.php/Pam_debugging_funktion ( /etc/pam_debug) và http://nixdoc.net/man-pages/HP-UX/man4/pam.conf.4.html ( debugtùy chọn trên các mục nhập PAM trong /etc/pam.d/).

Không, không hoạt động. Không có đầu ra PAM, không có gì, im lặng tuyệt đối.

Trong khi tìm kiếm một giải pháp, tôi thậm chí đã theo các liên kết đến Pam, đó là các trạm xăng ở Đức. Chà, vâng, có lẽ trong tất cả hàng tỷ lượt truy cập đó có thể che giấu một manh mối, nhưng hãy bắn tôi tôi sẽ chết trước khi tôi phát hiện ra.

Phần còn lại là FYI:

Tôi có vấn đề gì?

Sau khi nâng cấp lên Debian Bóp một cái gì đó trở nên kỳ lạ (ừm, nó đã từng là, uh, cái gì đúng với Etch .. ah, vâng, Woody). Vì vậy, đây có thể không phải là lỗi của Debian, chỉ là một thiết lập sai lầm kéo dài. Tôi ngay lập tức có ấn tượng rằng nó phải làm gì đó với PAM, nhưng tôi thực sự không biết chuyện gì đang xảy ra. Tôi hoàn toàn chìm trong bóng tối, bị bỏ lại một mình, bất lực khi còn bé, YKWIM. Một số đăng nhập ssh làm việc, một số không. Đó là loại buồn cười. Không có manh mối trong ssh -v, không có manh mối trong /var/log/*, không có gì. Chỉ "auth thành công" hoặc "auth fail", đôi khi cùng một người dùng đăng nhập thành công song song với một phiên và thất bại với phiên khác, cùng một lúc. Và không có gì bạn thực sự có thể có được giữ.

Sau khi đào các khối lượng xe lửa của các tùy chọn khác, tôi đã có thể tìm hiểu. Có nullokvà nullok_secure, một bản đặc biệt của Debian. Một cái gì đó sai lệch /etc/securettyvà tùy thuộc vào tty(điều này hơi ngẫu nhiên) một đăng nhập đã bị từ chối hay không. THẬT SỰ, phew!

Việc khắc phục rất dễ dàng và mọi thứ giờ đã ổn trở lại.

Tuy nhiên điều này để lại cho tôi câu hỏi, làm thế nào để gỡ lỗi một mớ hỗn độn như vậy trong tương lai. Đây không phải là lần đầu tiên PAM khiến tôi phát điên. Vì vậy, tôi muốn xem một giải pháp cuối cùng. Chung kết như trong "giải quyết", không phải cuối cùng như trong "armageddon". Cảm ơn.

Ah, BTW, điều này một lần nữa củng cố niềm tin của tôi rằng thật tốt khi ghét PAM kể từ khi nó xuất hiện. Tôi đã đề cập rằng tôi làm?

Một vài điều để bạn thử:

Bạn có cho phép ghi nhật ký các thông báo gỡ lỗi trong syslog không?

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

Thêm dòng sau:

*.debug     /var/log/debug.log

Thoát với :wq!.

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

Bạn có thể bật gỡ lỗi cho tất cả các mô-đun như vậy:

touch /etc/pam_debug

HOẶC bạn chỉ có thể bật gỡ lỗi cho các mô-đun bạn quan tâm bằng cách thêm "gỡ lỗi" vào cuối các dòng có liên quan trong /etc/pam.d/system-authhoặc các /etc/pam.d/*tệp khác :

login   auth    required    pam_unix.so debug

Sau đó, thông báo gỡ lỗi sẽ bắt đầu xuất hiện trong /var/log/debug.log. Hy vọng điều này sẽ giúp bạn ra ngoài!

Ít nhất trên CentOS 6.4, /etc/pam_debugKHÔNG được sử dụng.

Nếu mô-đun pam_warn.so được cài đặt, bạn có thể nhận được một số đầu ra đăng nhập theo cách này:

auth required pam_warn.so

success required pam_warn.so

vv Mô-đun này đảm bảo rằng nó sẽ không can thiệp vào quá trình xác thực tại bất kỳ thời điểm nào, nhưng nó ghi lại những thứ có ý nghĩa thông qua syslog.

Cập nhật

Sau khi kiểm tra mã và thực hiện một số biên dịch, tôi thấy rằng (1) có thể kích hoạt chế độ gỡ lỗi này thông qua nguồn và (2) bản vá RHEL làm cho tính năng gần như không thể sử dụng được (ít nhất là mô-đun pam_unix) và (3) có lẽ tốt hơn để vá mã nào.

Để làm việc này cho RHEL, bạn có thể lấy Linux-PAM ... src.rpm (cho bất kỳ phiên bản 1.1 nào) và thay đổi tệp spec như sau:

• Tìm dòng bắt đầu bằng

  % cấu hình \

và sau đó, thêm --enable-debug \

• Xóa dòng hoặc nhận xét dòng (trên dòng trước) bắt đầu bằng% patch2

Sau đó xây dựng vòng / phút và cài đặt (với lực, để ghi đè lên các gói hiện có). Bây giờ hãy tạo tập tin /var/run/pam-debug.log:

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

Nếu tệp không tồn tại, đầu ra gỡ lỗi sẽ được gửi đến thiết bị lỗi chuẩn.

• Theo tôi, việc gửi ra stderr này là ngu ngốc và là nguyên nhân gây ra xung đột bản vá. Bạn có thể thay đổi hành vi đó bằng cách vào tệp libpam / include / security / _pam_macros.h và thay thế 4 dòng

  logfile = stderr;

với

return;

Khi xây dựng, bạn sẽ nhận được cảnh báo về các tuyên bố không thể truy cập, nhưng chúng có thể bị bỏ qua. Bạn có thể thực hiện thay đổi này trong tập lệnh sed (và đặt nó vào phần% Prep của RPM sau các bản vá) ...

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

NẾU bạn thực hiện bản vá nhỏ này, bạn có thể khôi phục% patch2, vì nó sẽ hoạt động trở lại đúng cách.

Tôi tình cờ dành vài giờ để cố gắng tìm hiểu cách bật nhật ký gỡ lỗi trong PAM trên CentOS 6.4. Mặc dù câu hỏi này là dành cho Debian, tôi vẫn sẽ viết ra cách thực hiện trên CentOS với hy vọng rằng những người khác không phải đặt thời gian mà tôi đã có.

Cuối cùng, việc bật nhật ký gỡ lỗi trong pamgói CentOS rất đơn giản. Khó khăn bắt nguồn từ thực tế là nó liên quan đến việc biên dịch lại gói. Vì vậy, trước tiên hãy tìm SRPM (ví dụ pam-1.1.1-13.el6.src.rpm) từ đây . Folks người không biết về soạn thảo gói từ SRPMS, có thể tham khảo các bước trên việc thiết lập một môi trường RPM xây dựng .

Đây là bước chính. Mở tệp spec và thêm --enable-debugvào %buildphần trong configurelời gọi. Biên dịch lại! Cài đặt lại gói vừa tạo. Cuối cùng, tạo tệp nơi nhật ký gỡ lỗi sẽ được ghi.

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

Nếu bạn không tạo tệp thì rất nhiều nhật ký sẽ xuất hiện ở thiết bị đầu cuối, điều này có thể không hữu ích lắm.

Debian và Ubuntu (và có thể các bản phân phối khác) có tệp nhật ký đặc biệt mà tất cả đầu ra pam được ghi lại:

/var/log/auth.log

Tôi đã vật lộn với một vấn đề liên quan đến pam trong một ngày rưỡi, cuối cùng đã tìm ra tệp nhật ký này và tự cứu mình khỏi sự điên rồ.

Đây là một mẫu nội dung của tệp này khi mọi thứ không đi theo kế hoạch.

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

Đây là giao diện khi nó hoạt động:

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)

Lưu ý rằng không có khả năng nào khác để cho phép ghi nhật ký gỡ lỗi pam làm việc cho tôi.

Một cái gì đó vặn vẹo với / etc / securetty và tùy thuộc vào tty (có phần ngẫu nhiên) một đăng nhập đã bị từ chối hay không. THẬT SỰ, phew!

Bạn có thể mở rộng về điều đó một chút?

Trang web của mỗi securetty :

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

Hành vi bạn mô tả nghe có vẻ khá giống như securetty đang hoạt động bình thường (giả sử bạn thực sự đang đăng nhập với quyền root).

Một số đăng nhập ssh làm việc, một số không.

Ở đây cũng vậy, có thể có những hạn chế không phải PAM, vì vậy nó có thể giúp cung cấp một số cái nhìn sâu sắc về /etc/ssh/sshd_configdiện mạo của bạn .

Đáng chú ý, từ mô tả của bạn:

• nếu bạn đang cố gắng đăng nhập với quyền root và thất bại, thì đó có thể là do dòng này hiện diện trong sshd_config:PermitRootLogin no
• nếu một số người dùng / nhóm làm việc, và những người khác không, một trong những lý do có thể là việc sử dụng trong sshd_configcác AllowGroupshoặc AllowUsers. Một dòng mẫu có thể trông giống như: AllowGroups users admins

Tất nhiên PAM hoàn toàn có thể là một phần của vấn đề, nhưng âm thanh 'triệu chứng' chính của bạn đối với tôi giống như chúng có thể được giải thích bằng các phương tiện khác.

Asket ... Tôi thực sự yêu bài viết của bạn :) Tôi đã chiến đấu với những thứ như thế này trong 15 giờ qua ... (tôi có thể đã nghỉ 30 phút)

Bằng cách nào đó tôi đã làm cho nó hoạt động bằng cách làm tất cả những thứ bạn đã làm, điều đó có nghĩa là tôi có / etc / pam_debug và gỡ lỗi trên các mục pam. NHƯNG như trong trường hợp của tôi, tôi đã phải vật lộn với pam_mysql, tôi đã phải đặt một cái khác verbose=1sau khi debugvào mục pam của tôi:

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" đó chỉ là để ghi nhật ký trong DB.

Vì vậy, có lẽ điều này giúp bạn một chút.

Tất cả chúng ta đều ghét PAM. Chúc may mắn!