Làm cách nào để sử dụng máy chủ ssh với PAM nhưng không cho phép mật khẩu auth?


13

Nhiều hướng dẫn cho bạn biết cấu hình máy chủ ssh của bạn như thế này:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no 

nhưng với thiết lập này, bạn không thể sử dụng PAM, vì tôi dự định sử dụng 2 Factor Auth với Google Authenticator (OTP Onetime Password) tôi cần PAM.

Vậy làm thế nào để cấu hình một debian jessie ssh deamon mới, nếu tôi muốn ngăn đăng nhập bằng mật khẩu bình thường nhưng vẫn cho phép sử dụng PAM.

Có lẽ câu hỏi chính xác là làm thế nào để cấu hình pam để không cho phép mật khẩu?

Chi tiết về Xác thực PAM

Vô hiệu hóa xác thực mật khẩu dựa trên PAM là không trực quan. Nó là cần thiết trên hầu hết tất cả các bản phân phối GNU / Linux (ngoại trừ đáng chú ý là Slackware), cùng với FreeBSD. Nếu bạn không cẩn thận, bạn có thể đặt Mật khẩu xác thực thành 'không' và vẫn đăng nhập chỉ bằng mật khẩu thông qua xác thực PAM. Hóa ra bạn cần đặt 'ChallengeResponseAuthentication' thành 'no' để thực sự vô hiệu hóa xác thực PAM. Các trang người dùng FreeBSD có điều này để nói, điều này có thể giúp làm rõ tình hình một chút:

Lưu ý rằng nếu ChallengeResponseAuthentication là 'có' và chính sách xác thực PAM cho sshd bao gồm pam_unix (8), xác thực mật khẩu sẽ được cho phép thông qua cơ chế phản hồi thử thách bất kể giá trị của PasswordAuthentication.

http://www.unixlore.net/articles/five-minutes-to-more-secure-ssh.html

Câu trả lời:


23

Có lẽ câu hỏi chính xác là làm thế nào để cấu hình pam để không cho phép mật khẩu?

Chính xác. Bạn đã vấp phải sự thật rằng thiết lập UsePAM nonói chung là lời khuyên tồi. Nó không chỉ ngăn chặn bất kỳ hình thức xác thực dựa trên PAM nào, mà còn vô hiệu hóa accountsessioncác mô-đun. Kiểm soát truy cập và cấu hình phiên là những điều tốt.

Đầu tiên, hãy xây dựng một danh sách các yêu cầu:

  • OTP qua pam_google_authenticator.so. Điều này đòi hỏi UsePAM yesChallengeResponseAuthentication yes. Rốt cuộc, bạn đang nhắc họ cho một chứng chỉ!
  • Không có hình thức xác thực mật khẩu khác thông qua PAM. Điều này có nghĩa là vô hiệu hóa bất kỳ authmô-đun nào có thể cho phép mật khẩu được truyền qua thông tin keyboard-interactiveđăng nhập. (mà chúng tôi phải để lại cho OTP)
  • Xác thực dựa trên khóa. Chúng tôi cần yêu cầu publickeyxác thực và có thể gssapi-with-micnếu bạn đã cấu hình Kerberos.

Thông thường, xác thực bằng khóa bỏ qua xác thực hoàn toàn dựa trên PAM. Điều này sẽ khiến chúng tôi dừng theo dõi với các phiên bản mở rộng cũ hơn, nhưng Debian 8 (jessie) hỗ trợ AuthenticationMethodschỉ thị. Điều này cho phép chúng tôi yêu cầu nhiều phương thức xác thực, nhưng chỉ hoạt động với các máy khách triển khai SSHv2.


cấu hình sshd

Dưới đây là những dòng tôi đề nghị cho /etc/ssh/sshd_config. Hãy chắc chắn rằng bạn có một cách để truy cập hệ thống này mà không sshdtrong trường hợp bạn phá vỡ một cái gì đó!

# Require local root only
PermitRootLogin no

# Needed for OTP logins
ChallengeResponseAuthentication yes
UsePAM yes

# Not needed for OTP logins
PasswordAuthentication no

# Change to to "yes" if you need Kerberos. If you're unsure, this is a very safe "no".
GSSAPIAuthentication no


# Require an OTP be provided with key based logins
AuthenticationMethods publickey,keyboard-interactive

# Use this instead for Kerberos+pubkey, both with OTP
#
#AuthenticationMethods gssapi-with-mic,keyboard-interactive publickey,keyboard-interactive

Đừng quên tải lại sshdsau khi những thay đổi này được thực hiện.

Cấu hình PAM

Chúng ta vẫn phải cấu hình PAM. Giả sử cài đặt sạch Debian 8 (theo câu hỏi của bạn):

  • Nhận xét @include common-authtừ /etc/pam.d/sshd.
  • Xem lại /etc/pam.d/sshdvà xác nhận rằng không có dòng bắt đầu với authhiện tại. Không nên có nếu đây là một bản cài đặt sạch, nhưng tốt nhất là an toàn.
  • Thêm một authmục cho pam_google_authenticator.so.

Hãy nhớ rằng mật khẩu cục bộ vẫn hoạt động.

Chúng tôi đã không thực hiện bất kỳ thay đổi nào sẽ ảnh hưởng đến thông tin đăng nhập thông qua bảng điều khiển cục bộ hoặc ngăn người dùng sử dụng mật khẩu để nâng cấp các đặc quyền của họ thông qua sudo.Điều này nằm ngoài phạm vi của câu hỏi. Nếu bạn quyết định đưa mọi thứ đi xa hơn, hãy nhớ rằng root phải luôn được phép đăng nhập cục bộ qua mật khẩu. Bạn có nguy cơ tự khóa mình ra khỏi hệ thống.


chưa thử nghiệm nhưng nó có vẻ hợp lý và với 5 lần nâng cấp tôi nghĩ tôi có thể chấp nhận nó.
c33s

Tôi đã tự kiểm tra. nếu bạn muốn vô hiệu hóa hoàn toàn mật khẩu, bạn cũng phải đặt ChallengeResponseAuthentication no. xem blog.tankywoo.com/linux/2013/09/14/ Mạnh
ẩn danh

@anonymous Tham khảo câu hỏi của OP và viên đạn đầu tiên. Vô hiệu hóa ChallengeResponseAuthenticationphá vỡ phương thức xác thực tương tác bàn phím, cần thiết cho các mô-đun xác thực PAM xử lý OTP. (mong muốn của OP) Vô hiệu hóa CRA chỉ an toàn để thực hiện nếu bạn thực sự không có mô-đun PAM nào trong authngăn xếp cần kích hoạt. Nếu PasswordAuthenticationGSSAPIAuthenticationbị vô hiệu hóa, mật khẩu sẽ không được chấp nhận trừ khi PAM có mô-đun xác thực được bật yêu cầu.
Andrew B

(nói rằng, nó vẫn là một liên kết tuyệt vời)
Andrew B

0

không cho phép yêu cầu mật khẩu

bình luận dòng này

#auth       substack     password-auth

trong /etc/pam.d/sshd

và chắc chắn không có nullok ở cuối dòng này trừ khi sẽ xác thực qua ssh mà không cần sử dụng OTP

auth required pam_google_authenticator.so
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.