Sự khác biệt giữa ! đấu với !! vs * trong / etc / bóng


38

Trường thứ hai trong /etc/shadowtệp Linux biểu thị mật khẩu. Tuy nhiên, những gì chúng ta đã thấy là:

  1. Một số trường mật khẩu có thể có một dấu chấm than

    <account>:!:.....
    
  2. Một số trường mật khẩu có thể có dấu chấm than kép

    <account>:!!:.....
    
  3. Một số trường mật khẩu có thể có dấu hoa thị

    <account>:*:.....
    

Bằng một số nghiên cứu trên internet và thông qua chủ đề này , tôi có thể hiểu điều đó *có nghĩa là mật khẩu không bao giờ được thiết lập, !có nghĩa là bị khóa.

Ai đó có thể giải thích câu cảm thán kép ( !!) có nghĩa là gì không? và nó khác với ( !) như thế nào?


Phân phối nào bạn đang sử dụng?
muru

Xin chào Muru, tôi mới sử dụng Unix và đang cố gắng tạo một tập lệnh sẽ chạy trên RHEL 6.6 và HP-UX B.11.23
JavaTec

3
"Theo quy ước, các tài khoản không có ý định đăng nhập vào (ví dụ bin, daemon, sshd) chỉ chứa một dấu sao trong trường mật khẩu. Lưu ý rằng không có gì đặc biệt về '*', nó chỉ là một trong nhiều ký tự không thể xảy ra trong mật khẩu được mã hóa hợp lệ (xem mật mã (3)). " - Trang người dùng OpenBSD cho passwd (5) . Tôi mong chờ ! hoặc là !! về mặt kỹ thuật, không khác nhau, liên quan đến việc đó là một tệp mật khẩu hợp lệ hay liên quan đến thông tin đăng nhập. Tuy nhiên, một số công cụ có thể có hỗ trợ đặc biệt.
TUYỆT VỜI

1
Đừng sử dụng tài liệu của BSD làm tài liệu tham khảo cho việc này. Cơ sở dữ liệu tài khoản của họ xử lý mọi thứ khác nhau và thậm chí không có /etc/shadowtệp. Đừng đưa câu trả lời vào bình luận . ☺
JdeBP

Câu trả lời:


31

Cả "!" và "!!" có mặt trong trường mật khẩu có nghĩa là một tài khoản bị khóa.

Vì nó có thể được đọc trong tài liệu sau, "!!" trong một tài khoản trong bóng có nghĩa là tài khoản của người dùng đã được tạo, nhưng chưa được cung cấp mật khẩu. Cho đến khi được sysadmin cấp mật khẩu ban đầu, nó sẽ bị khóa theo mặc định.

https://access.redhat.com/documentation/en-US/Red_Hat_ Entryprise_Linux / 4


4
Điều này có thể đúng trên các hệ thống Red Hat, nhưng không nhất thiết phải ở nơi khác - trên Ubuntu hoặc Arch Linux, một tài khoản mới được tạo không có mật khẩu vẫn chỉ có !, không !!.
muru

2
Thực sự là tôi chưa bao giờ thấy một "!!" trong một hệ thống Debian. Tôi đoán OP đang sử dụng một số hệ thống dựa trên RH, hoặc SuSE.
Rui F Ribeiro

Cảm ơn bạn đã trả lời nhanh chóng, liệu lời giải thích trên được cung cấp bởi Rui - có tốt cho hp-ux không?
JavaTec

4
@JavaTec Không nhất thiết: Tôi nghĩ rằng tất cả các thông báo có /etc/shadowcùng một trường nhưng cách trường mật khẩu lưu trữ thông tin không phải mật khẩu khác nhau. Kiểm tra tài liệu HP-UX, bắt đầu với shadowtrang man.
Gilles 'SO- ngừng trở nên xấu xa'

1
HP-UX thậm chí không có /etc/shadowcho đến gần đây: trước HP-UX 11.11, các tùy chọn là không bóng cổ điển /etc/passwdhoặc "Cơ sở tính toán đáng tin cậy", lưu trữ từng băm mật khẩu của người dùng và thông tin tài khoản khác trong các tệp riêng lẻ /tcb/files/auth/<initial>/<username>có thể đọc được bằng root. Trong HP-UX 11.11, /etc/shadowđược giới thiệu là một tùy chọn bổ sung , vào 11,23, nó là một tùy chọn trong HĐH cơ sở và trong 11,31, TCB cuối cùng đã bị từ chối.
telcoM

10

Nó cũng có thể đáng chú ý <account>::.....có nghĩa là không có mật khẩu cần thiết (mật khẩu trống).

Nếu bạn đang tạo một người dùng chỉ ssh, bạn có thể sử dụng <account>::0:0:99999:7:::để yêu cầu người dùng đó đặt mật khẩu của họ (tức là họ sử dụng cho sudo) trong lần đăng nhập đầu tiên của họ.


8
Coi chừng việc này. Trường trống có nghĩa là không có mật khẩu và bạn chỉ cần nhấn ENTER để đăng nhập, ít nhất là trong bảng điều khiển.
Rui F Ribeiro

Từ trường man shadowliên quan đến mật khẩu được mã hóa: "Trường này có thể trống, trong trường hợp đó, không có mật khẩu nào được yêu cầu để xác thực là tên đăng nhập được chỉ định." <- Rời khỏi trường này kết quả emtpy trong tài khoản mở và điều này thực sự nên tránh!
Laas

Lưu ý rằng nhiều triển khai SSH chặn đăng nhập vào tài khoản mật khẩu null theo mặc định: sudo /usr/sbin/sshd -T| grep emptysẽ trả về: "allowemptypasswords no"
Brian Huntley
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.