Làm thế nào để mở khóa tài khoản cho ủy quyền ssh khóa công khai, nhưng không cho phép mật khẩu?


32

Ssh sẽ không cho phép tôi đăng nhập, vì tài khoản đã bị khóa. Tôi muốn mở khóa người dùng trên máy chủ của mình để ủy quyền khóa công khai trên ssh, nhưng không kích hoạt đăng nhập bằng mật khẩu.

Tôi đã thử:

# passwd -u username
passwd: unlocking the password would result in a passwordless account.
You should set a password with usermod -p to unlock the password of this account.

Các mục nhật ký xác thực:

Mar 28 00:00:00 vm11111 sshd[11111]: User username not allowed because account is locked
Mar 28 00:00:00 vm11111 sshd[11111]: input_userauth_request: invalid user username [preauth]

bạn nên (IMHO) làm điều này cho tất cả người dùng ... một cấu hình đơn giản khi thực hiện nó cho toàn bộ sshd
Skaperen 28/03/2015

passwd -ulà một ý tưởng tồi Xem câu trả lời của Giles dưới đây.
Peter Jenkins

Câu trả lời:


15

Mở khóa tài khoản và cung cấp cho người dùng mật khẩu phức tạp như @Skaperen gợi ý.

Chỉnh sửa /etc/ssh/sshd_configvà đảm bảo bạn có:

PasswordAuthentication no

Kiểm tra xem dòng không được nhận xét ( #lúc bắt đầu) và lưu tệp. Cuối cùng, khởi động lại sshddịch vụ.

Trước khi bạn làm điều này, hãy đảm bảo rằng xác thực khóa công khai của bạn đang hoạt động trước tiên.

Nếu bạn chỉ cần làm điều này cho một (hoặc một số lượng nhỏ) người dùng, hãy PasswordAuthenticationbật và thay vào đó sử dụng Match User:

Match User miro, alice, bob
    PasswordAuthentication no

Đặt ở dưới cùng của tệp vì nó hợp lệ cho đến Matchlệnh tiếp theo hoặc EOF.

Bạn cũng có thể sử dụng Match Group <group name>hoặc phủ địnhMatch User !bloggs

Như bạn đã đề cập trong các bình luận, bạn cũng có thể đảo ngược nó để Xác thực mật khẩu bị vô hiệu hóa trong phần chính của cấu hình và sử dụng các Matchcâu lệnh để kích hoạt nó cho một vài người dùng:

PasswordAuthentication no
.
.
.
Match <lame user>
    PasswordAuthentication yes

Tôi có ấn tượng Miro muốn vô hiệu hóa mật khẩu chỉ cho một lần sử dụng. nhưng hãy xem nhận xét trước đó của tôi
Skaperen 28/03/2015

@Skaperen - bạn cũng có thể đúng. Tôi đã thay đổi câu trả lời của tôi một chút.
garethTheRed 28/03/2015

MatchCú pháp đó có vẻ tốt, nhưng tôi sẽ thử đảo ngược nó. Cho phép đăng nhập bằng mật khẩu cho người dùng (vài người khập khiễng).
kravemir 28/03/2015

@Miro - Đó là một ý tưởng hay, tôi đã thêm nó vào câu trả lời của mình để tham khảo trong tương lai.
garethTheRed 28/03/2015

37

Dù bạn làm gì, đừng để tài khoản ở trạng thái còn lại passwd -u, với trường mật khẩu trống: cho phép đăng nhập mà không cần nhập mật khẩu (ngoại trừ SSH, vì SSH từ chối điều đó).

Thay đổi tài khoản để không có mật khẩu, nhưng được mở khóa. Tài khoản không có mật khẩu nếu băm mật khẩu trong cơ sở dữ liệu mật khẩu không phải là băm của bất kỳ chuỗi nào. Theo truyền thống, một chuỗi một ký tự như *hoặc !được sử dụng cho điều đó.

Các tài khoản bị khóa cũng sử dụng một điểm đánh dấu đặc biệt trong trường mật khẩu khiến chuỗi không phải là hàm băm của bất kỳ chuỗi nào. Điểm đánh dấu phụ thuộc vào hệ thống. Trên Linux, passwdlệnh đánh dấu mật khẩu bị khóa bằng cách đặt dấu !ở đầu và OpenSSH coi tài khoản là bị khóa nếu trường bắt đầu bằng !. Các biến thể Unix khác có xu hướng sử dụng các cơ chế tương tự nhưng không giống nhau, vì vậy hãy cẩn thận nếu cơ sở dữ liệu mật khẩu của bạn được chia sẻ giữa một mạng không đồng nhất.

Trên Linux, bạn có thể vô hiệu hóa quyền truy cập dựa trên mật khẩu vào tài khoản trong khi cho phép truy cập SSH (với một số phương thức xác thực khác, thường là một cặp khóa) với

usermod -p '*' username

Người dùng sẽ không thể thay đổi tài khoản trở lại bằng mật khẩu, vì điều đó yêu cầu họ nhập mật khẩu hợp lệ.

Thay vào đó, nếu bạn muốn, bạn có thể định cấu hình SSH để từ chối xác thực mật khẩu, bất kể tài khoản có mật khẩu hay không. Bạn vẫn cần sắp xếp để SSH không coi tài khoản bị khóa, vì vậy, ví dụ trên Linux, bạn sẽ cần xóa !trường mật khẩu (nhưng không làm trống trường - đặt thành *như đã giải thích ở trên ). Để vô hiệu hóa xác thực mật khẩu cho SSH, hãy thêm một lệnh PasswordAuthenticationvào /etc/sshd_confighoặc /etc/ssh/sshd_config(bất cứ khi nào nó có trên hệ thống của bạn). Sử dụng một Matchkhối để làm cho lệnh đó chỉ áp dụng cho một người dùng cụ thể; Matchkhối phải xuất hiện

…
Match User username
    PasswordAuthentication no

6
Cảm ơn - usermod -p '*' usernameđã làm việc say mê!
Homme Zwaagstra

1
OpenSSHd không cho phép người dùng bị khóa (tức là băm mật khẩu có !tiền tố) đăng nhập bằng một số phương thức xác thực khác nếu UsePAM yesđược đặt sshd_config. Đây có lẽ là mặc định với hầu hết các bản phân phối (ví dụ với Fedora).
maxschlepzig

1
Tôi có một hệ thống nhúng không có PAM, vì vậy sự khác biệt '*'so với '!'siêu hữu ích.
jpkotta

8

Bạn không cần bật hoặc đặt mật khẩu và bạn thực sự không nên, nếu bạn đã sử dụng các phím mạnh. Chỉ cần khóa lại tài khoản của bạn (tên người dùng sudo passwd -l) từ một phiên hiện có và sửa cấu hình SSH của bạn.

Lý do tại sao điều này xảy ra có lẽ là do bạn đã chỉnh sửa một trong các cài đặt SSH daemon mặc định (trong / etc / ssh / sshd_config).

Thay đổi điều này trong / etc / ssh / sshd_config và khởi động lại SSH:

UsePAM yes

Nói chung, trừ khi bạn có lý do thực sự tốt để vô hiệu hóa PAM, tôi khuyên bạn nên duy trì kích hoạt nó; bật PAM trong SSH sẽ cho phép bạn vẫn đăng nhập, ngay cả khi đã xóa mật khẩu. Dù bạn làm gì, đừng đặt mật khẩu trống hoặc tương tự ... khóa trường mật khẩu không có nghĩa là khóa toàn bộ tài khoản của bạn.

Mẹo nhanh khi nhắn tin với SSH: giữ một phiên khác mở (trong một cửa sổ khác) bất cứ khi nào thay đổi cấu hình SSH của bạn và sau đó kiểm tra rằng bạn vẫn có thể đăng nhập; nếu bạn vô tình phá vỡ quyền truy cập của mình, hãy sử dụng phiên hiện tại của bạn để khắc phục nó.

(Tuyên bố miễn trừ trách nhiệm: Tôi làm việc tại Userify, nơi cung cấp phần mềm quản lý khóa SSH.)


0

Tôi gặp vấn đề này trên CentOS 7. Tôi là một người dùng Linux dựa trên Debian thông thường nên tôi là một con cá ra khỏi nước. Tôi nhận thấy rằng trong một số máy chủ, nó hoạt động và chỉ trong một máy chủ thì không. Kiểm toán.log cho biết không có gì hữu ích và Secure.log cũng không cung cấp bất cứ điều gì. Tôi thấy rằng sự khác biệt thực sự duy nhất là một số khác biệt về bối cảnh bảo mật trên các tệp và thư mục giữa những tệp không hoạt động và những thứ không hoạt động. Nhận bảo mật với

sudo ls -laZ <user-home>/.ssh

của thư mục (Tôi giả sử rất nhiều mặc định trên sshd_config).

Bạn sẽ thấy một số ssh_home_tuser_home_tthuộc tính. Nếu bạn không, sử dụng chconlệnh để thêm các thuộc tính bị thiếu.

Ví dụ

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

Trong trường hợp của tôi, sự nghi ngờ của tôi là người dùng đã được tạo theo cách không chuẩn. Nhà của ông là một thư mục trong /var/lib.

Thêm thông tin trong: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh- trái_keys-446469538 /


-2

mở khóa tài khoản và thay đổi mật khẩu thành một chuỗi ngẫu nhiên

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.