Cách tiếp cận nhất quán và an toàn cho các tài khoản không mật khẩu bằng SSH


12

Tôi phải thừa nhận rằng tôi thích máy chủ không có mật khẩu trong một số trường hợp. Một máy chủ điển hình dễ bị tổn thương đối với bất kỳ ai có quyền truy cập vật lý vào nó. Vì vậy, trong một số trường hợp, nó là thực tế để khóa nó về mặt vật lý và từ đó tin tưởng bất kỳ truy cập vật lý nào .

Các khái niệm cơ bản

Về lý thuyết, khi tôi tiếp cận một máy chủ như vậy, tôi sẽ có thể thực hiện các tác vụ quản trị mà không cần mật khẩu bằng cách nhập rootnhư đăng nhập và tôi không nên yêu cầu nhập mật khẩu. Điều tương tự có thể áp dụng cho tài khoản người dùng nhưng người ta sẽ không thực sự truy cập chúng. Do đó, không cần mật khẩu hệ thống để truy cập cục bộ (thỉnh thoảng).

Khi truy cập máy chủ từ xa, để quản trị hoặc cho tài khoản người dùng, tôi hy vọng sẽ luôn sử dụng khóa riêng SSH. Rất dễ dàng để thiết lập khóa SSH cho tài khoản vừa tạo và do đó không cần mật khẩu hệ thống để truy cập từ xa (thông thường).

# user=...
# 
# useradd -m "$user"
# sudo -i -u "$user"

$ keyurl=...
$
$ mkdir -p .ssh
$ curl -o .ssh/authorized_keys "$keyurl"

Kết luận là về lý thuyết, chúng tôi sẽ không nhận bất kỳ mật khẩu hệ thống nào cho các trường hợp sử dụng như thế. Vì vậy, câu hỏi là, làm thế nào để chúng ta cấu hình hệ thống và tài khoản người dùng để làm cho nó xảy ra một cách nhất quán và an toàn.

Chi tiết truy cập địa phương

Làm thế nào để chúng tôi đảm bảo tài khoản root có thể được truy cập cục bộ mà không cần mật khẩu? Tôi không nghĩ rằng chúng ta có thể sử dụng passwd -dvì điều đó sẽ khiến quyền truy cập root quá dễ dàng và người dùng không có khả năng có thể chuyển sang root miễn phí, điều đó là sai. Chúng tôi không thể sử dụng passwd -lvì nó ngăn chúng tôi đăng nhập.

Lưu ý rằng truy cập cục bộ chỉ dành riêng cho truy cập bằng bàn phím cục bộ. Do đó, một giải pháp hợp lệ không được cho phép bất kỳ người dùng chuyển đổi (dù sử dụng suhay sudo).

Chi tiết truy cập từ xa

Cho đến gần đây, giải pháp trên sẽ hoạt động nhưng bây giờ SSH bắt đầu kiểm tra tài khoản người dùng bị khóa. Chúng tôi có lẽ không thể sử dụng passwd -dcho cùng một lý do. Chúng ta không thể sử dụng passwd -uvì nó chỉ phàn nàn rằng nó sẽ dẫn đến những gì passwd -d.

Có một cách giải quyết với mật khẩu giả cho phần này.

user=...

echo -ne "$user:`pwgen 16`\n" | chpasswd

Cũng có thể tắt hoàn toàn việc kiểm tra tài khoản bị khóa trong SSH nhưng sẽ tốt hơn nếu giữ lại sự hỗ trợ của các tài khoản bị khóa và chỉ có thể mở khóa chúng.

Ghi chú cuối cùng

Điều tôi quan tâm là một giải pháp cho phép bạn đăng nhập vào tài khoản root cục bộ và tất cả các tài khoản bao gồm root từ xa mà không cần bất kỳ mật khẩu nào. Mặt khác, một giải pháp không được tác động đến bảo mật ngoại trừ theo những cách được mô tả rõ ràng, đặc biệt là không cho phép người dùng từ xa truy cập vào tài khoản root hoặc tài khoản của người dùng khác. Giải pháp phải đủ mạnh mẽ để không gây ra sự cố bảo mật một cách gián tiếp.

Một câu trả lời được chấp nhận và trao giải có thể hoặc không thể mô tả cấu hình chi tiết của các công cụ riêng lẻ nhưng phải chứa các điểm chính để đạt được các mục tiêu đã nêu. Lưu ý rằng điều này có lẽ không thể được giải quyết thông qua sử dụng thông thường của các công cụ như passwd, ssh, su, sudovà những thứ tương tự.

Thêm ý tưởng sau khi đọc câu trả lời đầu tiên

Chỉ cần một ý tưởng - truy cập root cục bộ có thể đạt được bằng cách bắt đầu shell gốc thay vì các quá trình đăng nhập. Nhưng vẫn cần khóa chỉ xác thực mật khẩu, không phải xác thực khóa công khai.


Sử dụng cấu hình PAM tùy chỉnh để truy cập cục bộ mà không cần mật khẩu và thực hiện tương tự cho đăng nhập sudo và SSH.
0xC0000022L

Câu trả lời:


5

Các yêu cầu mà tôi sẽ đưa ra giải pháp, như các gạch đầu dòng:

  1. Mật khẩu root không đăng nhập
  2. Mật khẩu từ xa đăng nhập từ người dùng được ủy quyền trước
  3. Đăng nhập từ xa không mật khẩu cho các tài khoản được chỉ định từ người dùng được ủy quyền trước
  4. Đăng nhập từ xa không mật khẩu cho bất kỳ tài khoản nào từ người dùng được ủy quyền trước

Các ví dụ sau dựa trên Debian, vì đó là những gì tôi đã có ở đây để thử nghiệm. Tuy nhiên, tôi thấy không có lý do tại sao các nguyên tắc không thể được áp dụng cho bất kỳ phân phối nào (hoặc thực sự là bất kỳ dẫn xuất * ix dựa trên PAM nào).

Mật khẩu root không đăng nhập

Tôi nghĩ rằng cách tôi sẽ tiếp cận điều này sẽ là tận dụng PAM và /etc/securettytệp cấu hình.

Là một điều kiện tiên quyết, mật khẩu gốc "đủ an toàn" phải được đặt. Điều này là không cần thiết để đăng nhập bảng điều khiển nhưng tồn tại để làm cho các nỗ lực bẻ khóa vũ phu trở nên không thực tế. Tài khoản này là một tài khoản root hoàn toàn bình thường.

Trong /etc/pam.d/loginTôi có bộ dòng chuẩn để xác thực (những dòng bắt đầu bằng từ khóa auth):

auth       optional   pam_faildelay.so  delay=3000000
auth [success=ok new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so
auth       requisite  pam_nologin.so

@include common-auth
auth       optional   pam_group.so

Tệp tham chiếu common-authbao gồm các dòng có liên quan sau đây:

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

Các common-authchỉ thị tập tin PAM để bỏ qua một quy tắc (các từ chối) nếu một "UNIX đăng nhập" thành công. Thông thường, điều này có nghĩa là một trận đấu trong /etc/shadow.

Các auth ... pam_securetty.sodòng được cấu hình để ngăn chặn đăng nhập root ngoại trừ trên các thiết bị tty quy định tại /etc/securetty. (Tệp này đã bao gồm tất cả các thiết bị bảng điều khiển.)

Bằng cách sửa đổi authdòng này một chút, có thể xác định quy tắc cho phép đăng nhập gốc mà không cần mật khẩu từ một thiết bị tty được chỉ định trong /etc/securetty. Các success=okthông số cần phải được sửa đổi để các okđược thay thế bằng số authdòng để được bỏ qua trong trường hợp có một trận đấu thành công. Trong tình huống hiển thị ở đây, con số đó là 3, nhảy xuống auth ... pam_permit.sodòng:

auth [success=3 new_authtok_reqd=ok ignore=ignore user_unknown=bad default=die] pam_securetty.so

Mật khẩu từ xa đăng nhập từ người dùng được ủy quyền trước

Đây là sự bao gồm đơn giản các khóa ssh cho những người dùng được ủy quyền được thêm vào authorized_keystệp gốc .

Đăng nhập từ xa không mật khẩu cho các tài khoản được chỉ định từ người dùng được ủy quyền trước

Đây cũng là sự bao gồm đơn giản các khóa ssh cho người dùng được ủy quyền được thêm vào .ssh/authorized_keystệp người dùng phù hợp và tương ứng . ( Chris người dùng từ xa điển hình muốn đăng nhập không mật khẩu vào kịch bản chris người dùng cục bộ .)

Lưu ý rằng các tài khoản có thể vẫn ở trạng thái khóa mặc định sau khi tạo (nghĩa là chỉ !trong trường mật khẩu cho /etc/shadow) nhưng cho phép đăng nhập dựa trên khóa SSH. Điều này yêu cầu root để đặt khóa trong .ssh/authorized_keystệp người dùng mới . Điều không rõ ràng là phương pháp này chỉ khả dụng khi UsePAM Yesđược đặt /etc/ssh/sshd_config. PAM phân biệt !là "tài khoản bị khóa vì mật khẩu nhưng các phương thức truy cập khác có thể được cho phép" và !..."tài khoản bị khóa. Thời gian." (Nếu UsePAM Nođược đặt, thì OpenSSH xem xét bất kỳ sự hiện diện nào của việc !bắt đầu trường mật khẩu để thể hiện tài khoản bị khóa.)

Đăng nhập từ xa không mật khẩu cho bất kỳ tài khoản nào từ người dùng được ủy quyền trước

Nó không hoàn toàn rõ ràng với tôi cho dù bạn muốn cơ sở này hay không. Cụ thể, một số người dùng được ủy quyền sẽ có thể đăng nhập ssh mà không cần mật khẩu cho bất kỳ tài khoản địa phương nào.

Tôi không thể kiểm tra kịch bản này nhưng tôi tin rằng điều này có thể đạt được với OpenSSH 5.9 hoặc mới hơn, cho phép authorized_keysxác định nhiều tệp /etc/ssh/sshd_config. Chỉnh sửa tệp cấu hình để bao gồm tệp thứ hai được gọi /etc/ssh/authorized_keys. Thêm khóa công khai của người dùng được ủy quyền đã chọn của bạn vào tệp này, đảm bảo quyền được sở hữu bởi root và chỉ có quyền truy cập ghi bằng root (0644).


Tôi sẽ phải kiểm tra số 1 cẩn thận hơn và kiểm tra nó. Nó trông rất thú vị, mặc dù nó vẫn yêu cầu mật khẩu (mạnh) được cấu hình. Số 3 không hoàn thành vì hiện tại người dùng mới được tạo cũng bị khóa theo mặc định từ đăng nhập SSH. Tôi đã không thực sự yêu cầu điểm 4 nhưng dù sao thì nó cũng rất thú vị và thực sự tôi có thể sử dụng phương pháp đó.
Pavel Šimerda

Mật khẩu mạnh cho root là bắt buộc nhưng không bao giờ được sử dụng. Tôi giả sử bạn biết cách thực hiện # 3; Hãy cho tôi biết nếu bạn cần thêm chi tiết. Trên các hệ thống (Debian) có thể ssh vào một tài khoản mới chưa có mật khẩu được xác định, miễn là .ssh/authorized_keystệp chứa khóa công khai có liên quan. Không giúp đỡ à?
roaima

Tôi nghĩ rằng tôi cần một cách hay và chuẩn để khôi phục hành vi mà bạn thấy trên Debian, tức là một tài khoản mới được tạo chỉ bị khóa để xác thực mật khẩu chứ không phải cho khóa công khai.
Pavel Šimerda

Đối với tài khoản người dùng thử nghiệm mà tôi đã tạo để xác nhận câu lệnh ssh trong nhận xét trước đó của mình, tôi thấy một tài khoản !trong trường mật khẩu /etc/shadow. Theo trang man, điều này cho biết một tài khoản hợp lệ mà không có mật khẩu nào có thể khớp được.
roaima

1
Điều đó thật thú vị, điều đó thực sự không quá rõ ràng , cảm ơn.
Pavel imerda 30/03/2015

1

Có vẻ như bạn muốn tài khoản người dùng thực (không phải root) có khóa ssh và NOPASSWDtruy cập đầy đủ thông qua sudo(có sẵn theo mặc định trong hầu hết các bản phân phối Linux hiện nay và cũng không đáng để cài đặt thủ công). Bạn có thể có mật khẩu trống cho mỗi tài khoản người dùng (sẽ không hoạt động từ xa), sau đó người dùng sẽ chạy sudo -shoặc người dùng ~/.bash_profilechỉ chứa lệnh đó.

Sudo

Thêm từng người dùng vào sudonhóm UNIX (ví dụ: usermod -a -G sudo USERNAMEmặc dù các hệ thống cũ hơn sẽ có cách trực quan ít hơn để thực hiện việc này; trường hợp xấu nhất, bạn chỉnh sửa /etc/groupstrực tiếp).

Trong /etc/sudoershoặc /etc/sudoers.d/local, bạn muốn một dòng như thế này:

%sudo    ALL=(ALL:ALL) NOPASSWD: ALL

Nếu bạn muốn truy cập root tự động, hãy thêm nó vào hồ sơ của người dùng. Đối với bash, đó sẽ là ~/.bash_profile:

sudo -s

Điều này sẽ cho phép bạn xem ai đã đăng nhập (thử whohoặc last) và sẽ để lại nhật ký /var/log/auth.log.

Mật khẩu đăng nhập

Trên các hệ thống lớn tuổi hơn, bạn chỉ có thể chỉnh sửa /etc/passwd(hoặc trên các hệ thống lớn hơn một chút, /etc/shadow) và loại bỏ các băm, vì vậy ví dụ như bob:$1$salt$hash:12345:0:99999:7:::chỉ trở nên bob::12345:0:99999:7:::. Đây là tất cả những gì bạn cần. Các hệ thống hiện đại không thích điều này. Có nhiều cách khác để làm điều này, nhưng cách tôi vừa xác minh là như sau (nguồn: Công cụ ngẫu nhiên của Leo ) :

Mở /etc/shadowvà quan sát một tài khoản với thông tin thực sự. Điều này sẽ bao gồm ba yếu tố được phân định bởi dấu đô la ( $). Chúng đại diện cho cơ chế băm, sau đó là muối , sau đó là băm. Lưu ý muối, sau đó chạy này:

openssl passwd -1 -salt SALT

(Điều này sử dụng MD5 làm cơ chế băm. Đó là mật khẩu trống, vì vậy bạn không nên bận tâm.) Khi được nhắc nhập mật khẩu, hãy nhấn enter. Lưu chuỗi đó, bao gồm bất kỳ dấu chấm nào và dán nó sau dấu hai chấm đầu tiên trên dòng của người dùng đó /etc/shadow(điều này sẽ thay thế bất kỳ nội dung nào tồn tại giữa dấu hai chấm đầu tiên và dấu hai chấm). (Vui lòng không sử dụng SALTnhư muối của bạn!)

SSH

sshCấu hình daemon của bạn sống trong /etc/sshd_confighoặc /etc/ssh/sshd_config. Để bảo mật chính xác, tôi khuyên bạn nên bao gồm các dòng sau:

PermitRootLogin no
PermitEmptyPasswords no

Xem phần ghi lại Secure Secure Shell để biết các biện pháp bảo mật bổ sung mà bạn có thể thêm vào cấu hình ssh của mình để làm cứng nó tốt hơn trước những kẻ tấn công tinh vi.

Bây giờ người dùng của bạn không thể đăng nhập thông qua sshdo có mật khẩu trống (đây là biện pháp bảo mật cần thiết). Điều này có nghĩa là họ chỉ có thể đăng nhập bằng các phím ssh.

Mỗi người dùng, cho mỗi hệ thống máy khách của họ, nên tạo một cặp khóa ssh, ví dụ:

ssh-keygen -t rsa -b 4096 -f $HOME/.ssh/id_rsa -o -a 100 -C "Bob Roberts on his laptop"

Điều này tạo ra một khóa riêng tại $HOME/.ssh/id_rsavà một khóa công khai tại $HOME/.ssh/id_rsa.pub. Yêu cầu người dùng đó gửi cho bạn khóa công khai của họ và nối chúng vào máy chủ này $HOME/.ssh/authorized_keys(lưu ý rằng mỗi người dùng $HOME/.sshphải ở chế độ 700, ví dụ mkdir -p ~user/.ssh && chmod 700 ~user/.ssh).

Người dùng không muốn khóa ssh có thể được chuyển qua hệ thống vật lý. Ở đó, mật khẩu trống của họ sẽ đăng nhập chúng, tại thời điểm đó họ có thể nhập passwdtừ trình bao và đặt mật khẩu, do đó cho phép họ truy cập từ xa.

(Tôi thực sự đã sử dụng kỹ thuật này để cung cấp cho mọi người quyền truy cập vào bộ sưu tập các hệ thống khi tôi điều hành bộ phận CNTT. Nó buộc người dùng phải sử dụng khóa ssh và tôi không phải cung cấp cho họ mật khẩu. Ban đầu họ ~/.bash_profilecó hai dòng ở phía dưới: passwdvà sau đó mv ~/.bash_profile.real ~/.bash_profilehọ đặt mật khẩu mới khi đăng nhập lần đầu.)

Rủi ro

Bạn đang đặt niềm tin hoàn toàn vào người dùng của bạn. Không có gì ngăn người dùng làm phiền với ~/.ssh/authorized_keystệp của người dùng khác và do đó thay đổi khả năng thu hồi và kiểm tra quyền truy cập của bạn, nhưng điều này là không thể tránh khỏi nếu bạn cấp quyền truy cập root đầy đủ.

Phần kết luận

Mỗi người dùng hiện là thành viên của nhóm sudo và có toàn quyền truy cập mật khẩu vào vỏ gốc. Những người dùng này không có mật khẩu cho tài khoản của họ và có thể đăng nhập từ xa bằng các phím ssh.

Nếu bạn mất một trong những nhân viên của mình, bạn có thể xóa tài khoản của anh ấy / cô ấy. Nếu một trong những máy tính xách tay của nhân viên của bạn bị đánh cắp, bạn có thể xóa khóa ssh của máy tính xách tay đó khỏi authorized_keystệp của người dùng đó . Nếu bạn có vi phạm bảo mật, bạn có nhật ký cho biết ai đã đăng nhập.


Phần về sudo bỏ lỡ câu hỏi vì nó chỉ dành riêng cho thông tin đăng nhập mới, không chuyển đổi người dùng. Sửa đổi câu hỏi để làm cho nó rõ ràng hơn. Phần về đăng nhập không mật khẩu thể hiện hành vi sai chính xác như passwd -dtrong câu hỏi, cho phép suchuyển sang người dùng đó mà không cần mật khẩu. Phần rủi ro mô tả hai điều (gây rối với dữ liệu của người dùng khác và có quyền truy cập root) mà việc xóa là điểm chính của câu hỏi. Do đó, trong khi các phần riêng lẻ được viết độc đáo, đây không có nghĩa là một câu trả lời cho câu hỏi.
Pavel Šimerda

Tôi giả sử bạn thêm người dùng và sau đó hạn chế người dùng.
Adam Katz
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.