Đặt mật khẩu sudo khác với mật khẩu đăng nhập


29

Là một người dùng đặc quyền, tôi đang cố gắng đặt sudomật khẩu cho người khác sau đó là mật khẩu được sử dụng khi đăng nhập.

Tôi đã thực hiện một số nghiên cứu nhưng chưa tìm thấy câu trả lời. Có sudohỗ trợ loại cấu hình đó không?

Nếu bạn mất mật khẩu, bạn sẽ mất tất cả. Ai đó có thể đăng nhập và quảng bá chính mình rootvới cùng một mật khẩu.

sudocó một tùy chọn để yêu cầu rootmật khẩu thay vì gọi mật khẩu người dùng, ( rootpw), nhưng chia sẻ rootmật khẩu chắc chắn không phải là một tùy chọn, đó là lý do tại sao chúng tôi thiết lập sudo.

Tôi đã làm config 2FAtrong quá khứ, nó hoạt động rất tốt, nhưng cũng đánh bại mục đích tự động hóa. Ví dụ: nếu bạn muốn thực thi một lệnh đặc quyền trên một tá máy chủ có expecttập lệnh, việc thêm 2FAkhông cho phép bạn làm điều đó.

Giải pháp gần nhất tôi đã tìm thấy là chỉ cho phép khóa riêng SSH và thiết lập cụm sudomật khẩu với một khóa khác với mật khẩu (đăng nhập). Tuy nhiên, nó không thoải mái, vì trong tình huống khẩn cấp, bạn không thể đăng nhập bằng PC khi không có khóa đó.


1
Tại sao bạn cần điều này chính xác? Có lẽ vấn đề là ở một nơi khác. Sẽ không tốt hơn nếu có xác thực hai yếu tố để đăng nhập vào hệ thống bằng tài khoản đặc quyền và sau đó có 'NOPASSWD', để sudo không yêu cầu mật khẩu? Sau đó, bạn nên có một tài khoản cục bộ khẩn cấp riêng biệt với mật khẩu mạnh để có thể đăng nhập khi mạng ngừng hoạt động (không có quyền truy cập ssh).
jirib

Câu trả lời:


30

Nếu bạn muốn hỏi mật khẩu gốc, trái ngược với mật khẩu của người dùng, có những tùy chọn mà bạn có thể đặt vào /etc/sudoers. rootpwđặc biệt sẽ làm cho nó yêu cầu mật khẩu root. Có runaspwtargetpwlà tốt; xem trang chủ sudoers (5) để biết chi tiết.

Ngoài ra, sudo thực hiện xác thực (như mọi thứ khác) thông qua PAM. PAM hỗ trợ cấu hình trên mỗi ứng dụng. Cấu hình của Sudo nằm trong (ít nhất là trên hệ thống Debian của tôi) /etc/pam.d/sudovà trông như thế này:

$ cat sudo 
#%PAM-1.0

@include common-auth
@include common-account
@include common-session-noninteractive

Nói cách khác, theo mặc định, nó xác thực như mọi thứ khác trên hệ thống. Bạn có thể thay đổi @include common-authdòng đó và để PAM (và do đó sudo) sử dụng nguồn mật khẩu thay thế. Các dòng không nhận xét trong chung-auth trông giống như (theo mặc định, điều này sẽ khác nếu bạn đang sử dụng, ví dụ: LDAP):

auth    [success=1 default=ignore]      pam_unix.so nullok_secure
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Bạn có thể sử dụng, ví dụ, pam_userdb.sothay vì pam_unix.sovà lưu trữ mật khẩu thay thế của mình trong cơ sở dữ liệu Berkeley DB.

thí dụ

Tôi đã tạo thư mục /var/local/sudopass, chủ sở hữu / nhóm root:shadow, chế độ 2750. Trong đó, tôi đã tiếp tục và tạo một tệp cơ sở dữ liệu mật khẩu bằng cách sử dụng db5.1_load(đó là phiên bản của Berkeley DB được sử dụng trên Debian Wheezy):

# ô 0027
# db5.1_load -h / var / local / sudopass -t hash -T passwd.db
anthony
WMaEFvCFEFplI
^D

Băm đó được tạo bằng mkpasswd -m des, sử dụng mật khẩu "mật khẩu". Rất an toàn! (Thật không may, pam_userdb dường như không hỗ trợ bất cứ điều gì tốt hơn so với crypt(3)băm cổ ).

Bây giờ, chỉnh sửa /etc/pam.d/sudovà xóa @include common-authdòng, và thay vào đó đặt nó vào vị trí:

auth    [success=1 default=ignore]      pam_userdb.so crypt=crypt db=/var/local/sudopass/passwd
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so

Lưu ý rằng pam_userdb thêm .dbtiện ích mở rộng vào cơ sở dữ liệu đã qua, vì vậy bạn phải .dbtắt.

Theo dannysauer trong một bình luận , bạn có thể cần phải thực hiện chỉnh sửa tương tự /etc/pam.d/sudo-i.

Bây giờ, để sudo, tôi phải sử dụng passwordthay vì mật khẩu đăng nhập thực sự của mình:

anthony @ sudotest: ~ $ sudo -K
anthony @ sudotest: ~ $ sudo echo -e '\ nit đã làm việc'
[sudo] mật khẩu cho anthony: passwordRETURN

nó đã làm việc

Đảm bảo cũng định cấu hình "sudo-i", phiên bản mới hơn của sudo thường sử dụng cho "sudo -i" (nếu nhà cung cấp không thay đổi điều gì đó).
dannysauer

Bạn có thể giải thích về cấu hình PAM không?
Shâu Shắc

@ ShâuShắc Tôi đã thêm một ví dụ, bao gồm các thay đổi cấu hình PAM.
derobert

Cảm ơn. Nhưng tôi không tìm thấy db51-utils ở bất cứ đâu trong Redhat / centos hoặc nguồn, nó chỉ có sẵn trong các biến thể Debian?
Shâu Shắc

3
" crypt(3)Băm cổ " trên các phiên bản hiện đại của glibc có hỗ trợ cho sha-512, vd. mkpasswd -m sha-512. pam_userdb.so có thể xử lý những thứ này tốt.
Andrew Domaszek

6

Đối với Redhat / Centos, yêu cầu có thể đạt được bằng các bước sau:

Tạo người dùng tùy chỉnh và vượt qua:

# db_load -t hash -T /usr/local/etc/passwd.db
user
pass
^d

Chỉnh sửa tệp sudo pam.d để nó trông giống như:

$ cat /etc/pam.d/sudo

auth            required        pam_userdb.so db=/usr/local/etc/passwd
account         required        pam_userdb.so db=/usr/local/etc/passwd
password        include         system-auth

session         optional        pam_keyinit.so revoke
session         required        pam_limits.so

Tôi vẫn đang tìm cách để cấu hình, để chỉ một người dùng / nhóm nhất định phải được xác thực theo phương thức tùy chỉnh này, những người khác vẫn có thể được xác thực theo phương thức xác thực hệ thống thông thường. Bất cứ ai có thể cho tôi một số lời khuyên?


Bạn sẽ có thể làm điều này với cú pháp hành động đầy đủ trong PAM. ví dụ: [user_unknown=ignore,success=ok,default=bad]... nhưng bạn sẽ phải chơi với nó (và đọc các tài liệu PAM) để làm cho đúng
derobert

Điều này cũng có thể được thực hiện bằng cách sử dụng pam_succeed_ifđể bỏ qua một mô-đun nếu người dùng nằm trong một trong danh sách các nhóm hoặc bỏ qua hai mô-đun nếu không.
dannysauer

Vì vậy, một cái gì đó nói chung là như thế này: /// auth [= thành công bỏ qua mặc định = 1] Người dùng pam_succeed_if.so trong danny: thẳng thắn /// auth đủ danny_frank_module.so /// auth đủ not_danny_frank.so
dannysauer

3

Tôi không nghĩ sudo hỗ trợ thiết lập như vậy. Mục đích của lời nhắc mật khẩu sudo là để đảm bảo rằng người ban hành lệnh sudo là cùng một người đã đăng nhập và cách dễ nhất để làm điều đó là yêu cầu người dùng hiện đang đăng nhập tự xác thực lại.

Nói cách khác, mục đích của dấu nhắc mật khẩu sudo không phải là để thiết lập thẩm quyền , nó là để thiết lập danh tính . Dựa trên danh tính đã được thiết lập và cấu hình sudo, quyết định có thể được đưa ra cho dù người dùng đang nghi vấn có quyền hạn hoặc quyền truy cập cần thiết hay không.


3
Sudo không (trừ trường hợp bạn muốn hỏi mật khẩu gốc, hoặc một người dùng cụ thể hoặc mật khẩu của người dùng đích), nhưng PAM thì có. Và sudo sử dụng PAM.
derobert

1

Mối quan tâm của bạn là mật khẩu tài khoản của bạn có thể được tiết lộ. Giải pháp là không sử dụng mật khẩu đăng nhập theo cách có thể tiết lộ. Với ssh, mật khẩu được mã hóa trên dây, vì vậy nó ổn. Mọi người tắt mật khẩu auth với ssh để ngăn chặn các cuộc tấn công đoán mật khẩu, không bảo vệ bí mật mật khẩu. Nếu bạn đang sử dụng cùng một mật khẩu tài khoản cho bất kỳ điều gì khác, hãy đảm bảo rằng bạn đang sử dụng kênh được mã hóa an toàn để cung cấp mật khẩu. Nếu bạn lo lắng về keylogger hoặc bất cứ điều gì, hãy ngừng sử dụng các máy không đáng tin cậy để đăng nhập.

Nếu ai đó có thể lấy mật khẩu ssh của bạn, họ cũng có thể lấy mật khẩu sudo thay thế, vì vậy bạn nên đầu tư thời gian để làm cho kết nối của mình an toàn hơn là dành thời gian chỉ khiến mọi thứ trở nên phức tạp hơn chỉ vì ảo tưởng về bảo mật hơn.


0

Tôi không có quyền truy cập ngay vào một hệ thống nơi tôi có thể kiểm tra điều này và tìm hiểu chi tiết, nhưng tôi có một ý tưởng:

  • (Giả sử tài khoản đăng nhập bình thường của bạn là shau.)
  • Tạo một tài khoản thứ hai : shau2. (Tôi không chắc liệu bạn có muốn nó có cùng UID không shau.)
  • Định cấu hình shau2để có các đặc quyền sudo với NOPASSWD.
  • Thiết lập bí danh hoặc tập lệnh shell để làm su shau2 -c sudo "$@". Điều này sẽ yêu cầu shau2mật khẩu. Nếu được nhập chính xác, nó sẽ chạy sudodưới dạng shau2 (không nên yêu cầu mật khẩu).
  • Xóa shauđặc quyền sudo.

Thật không may, bạn sẽ phải lặp lại điều này cho mọi người dùng có đặc quyền sudo.


0

Cảm ơn bạn @ Shâu Shắccâu trả lời ! Giải pháp đó cũng hoạt động cho LinuxMint 17.1 Cinnamon 32bit (Tôi chỉ cài đặt db-utilgói để chạy db_load).

Nhưng tôi rất bối rối với passwd.dbtập tin kết quả . Tôi đã làm giống như trong câu trả lời của bạn (nhưng được sử dụng davidjones , chúng trông bắt mắt hơn):

# db_load -t hash -T /usr/local/etc/passwd.db
david
jones
^d

Nhưng thông tin đăng nhập được lưu trữ bên trong tệp băm dưới dạng văn bản thuần túy:

# grep 'jones.*david'  /usr/local/etc/passwd.db
Binary file /usr/local/etc/passwd.db matches

Bạn cũng có thể thấy davidjones thông qua mcedit :

nhập mô tả hình ảnh ở đây

Có, có thể hạn chế quyền của /usr/local/etc/passwd.db. Nhưng dù sao, tên người dùng và mật khẩu được lưu trữ dưới dạng văn bản đơn giản là xấu.


Ngay cả với mật khẩu sudo riêng cũng có một số lỗ hổng bảo mật tiềm ẩn (theo thiết lập phân phối mặc định). Vì vậy, mật khẩu riêng biệt không áp dụng cho su (vì vậy có thể bắt đầu phiên root bằng sumật khẩu và đăng nhập). Ngoài ra, mật khẩu riêng biệt không được Bộ chính sách tôn trọng (có thể bắt đầu sử dụng Synaptic bằng synaptic-pkexecmật khẩu và đăng nhập. Sau đó xóa các gói ...). Những vấn đề này có thể được loại bỏ bằng cách điều chỉnh bổ sung các tập tin cấu hình.

Nhìn chung, dường như chỉ có thể đạt được mật khẩu sudo riêng biệt an toàn với sự trợ giúp của mô-đun PAM tùy chỉnh (có lẽ, mô-đun đó sẽ so sánh mật khẩu và hàm băm SHA-512 đọc từ tệp) hoặc chức năng SELinux.

PS: xin lỗi, nó nên là một bình luận Nhưng nó đi như câu trả lời vì định dạng văn bản. Cảm ơn vì đã hiểu.

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.