Linux ssh: cho phép xác thực khóa chung mà không cho người dùng quyền đọc khóa riêng

Người dùng đăng nhập vào máy chủ Linux của tôi sẽ có thể ssh đến một máy từ xa cụ thể có tài khoản mặc định. Xác thực trên máy từ xa sử dụng khóa chung, vì vậy trên máy chủ, khóa riêng tương ứng có sẵn.

Tôi không muốn người dùng máy chủ thực sự có thể đọc khóa riêng. Về cơ bản, việc họ có quyền truy cập vào máy chủ cho phép họ quyền ssh và việc xóa chúng khỏi máy chủ cũng sẽ không cho phép kết nối với máy từ xa.

Làm cách nào tôi có thể cho phép người dùng mở kết nối ssh mà không cho họ quyền truy cập đọc vào khóa riêng?

Suy nghĩ của tôi cho đến nay: rõ ràng ssh thực thi phải có khả năng đọc khóa riêng, vì vậy nó phải chạy dưới một người dùng khác trên máy chủ có quyền đó. Khi kết nối ssh được thiết lập, tôi có thể "chuyển tiếp" nó tới người dùng để anh ta có thể nhập lệnh và tương tác với máy từ xa.

• Đây có phải là một cách tiếp cận tốt?
• Làm thế nào tôi nên thực hiện về phía trước?
• Làm thế nào người dùng có thể khởi tạo kết nối (nghĩa là việc thực thi ssh bởi người dùng có quyền đọc trên khóa)?
• Có một lỗ hổng bảo mật? - nếu người dùng có thể thực thi ssh như một người dùng khác, thì họ có thể làm mọi thứ mà người dùng khác có thể (bao gồm, đọc khóa riêng) không?

Đó là một trong những lý do sudotồn tại. Chỉ cần cho phép người dùng của bạn chạy 1 lệnh duy nhất chỉ với các tùy chọn dòng lệnh được ủy quyền trước và hầu hết các biện pháp tránh né rõ ràng đều được giải quyết. ví dụ

#/etc/sudoers
%users ALL = (some_uid) NOPASSWD: /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

thiết lập sudođể tất cả các thành viên của nhóm userscó thể chạy lệnh ssh với tư cách là người dùng some_uid mà không cần nhập mật khẩu của riêng họ (hoặc tài khoản some_uid) khi họ chạy:

sudo -u some_uid /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

Xóa NOPASSWD:tùy chọn để buộc người dùng nhập mật khẩu của riêng họ trước khi đăng nhập vào máy chủ từ xa.
Có thể thiết lập một bí danh hoặc tập lệnh bao bọc để thuận tiện cho người dùng của bạn vì sudokhá kén chọn về việc sử dụng các đối số chính xác.

Đây có vẻ như là một trường hợp sử dụng tốt để xác thực dựa trên máy chủ. Đây là một phương thức xác thực trong đó SSH không sử dụng khóa của một người dùng cá nhân trên máy cục bộ (trong trường hợp này là máy chủ của bạn) để xác thực; thay vào đó, nó sử dụng khóa riêng của máy chủ lưu trữ , khóa được lưu trữ /etc/ssh/và chỉ có thể đọc được root.

Để thiết lập tính năng này, bạn sẽ cần tạo một tệp có tên .shoststrên máy từ xa, trong thư mục chính của người dùng mà bạn muốn mọi người đăng nhập dưới dạng (không phải trong ~/.ssh). Các tập tin nên có nội dung

server-hostname +

nơi server-hostnamelà tên của máy chủ của bạn, và +là một chữ dấu cộng phục vụ như là một ý nghĩa ký tự đại diện "bất kỳ người sử dụng".

Bạn cũng cần đảm bảo rằng máy từ xa có thể xác minh khóa máy chủ của máy chủ, điều đó có nghĩa là khóa máy chủ của máy chủ cần được liệt kê trong một /etc/ssh/ssh_known_hostshoặc ~/.ssh/known_hoststrên máy từ xa. Nếu đây chưa phải là trường hợp, bạn có thể thiết lập nó bằng cách đăng nhập vào máy từ xa và chạy

ssh-keyscan server-hostname >> /etc/ssh/ssh_known/hosts

Khi bạn đã thiết lập các bước này, bạn có thể xóa hoàn toàn khóa riêng trên máy chủ, nếu bạn không cần nó cho bất kỳ điều gì khác. (Và nếu bạn làm như vậy, bạn luôn có thể đặt nó ở chế độ chỉ có thể đọc được bằng rootmột cái gì đó.)

Bạn cũng có thể dễ dàng thực hiện những việc như cho phép hoặc từ chối một số người dùng truy cập vào máy từ xa. Xem các trang người đàn ông của sshvà hosts.equivđể biết chi tiết.

Một vấn đề với thiết lập này là người dùng đăng nhập vào máy từ xa có thể sửa đổi .shosts. Không có gì họ có thể làm điều đó cho phép họ đăng nhập vào máy từ xa như một người dùng khác, nhưng họ có thể cắt quyền truy cập của chính họ hoặc của người khác vào máy từ xa. Nếu đây là một mối quan tâm, bạn có thể .shostschỉ có thể ghi được bằng cách roothoặc một cái gì đó - tôi không chắc điều này có hiệu quả không, nhưng bạn có thể thử và xem. (Các phương pháp khác như phương pháp sudodễ bị rủi ro như nhau, vì người dùng luôn có thể xóa ~/.ssh/authorized_keys.)