Tôi thích thiết lập sau đây để quản lý quyền truy cập SSH, mà tôi sử dụng tại nơi làm việc để quản lý một nhóm người dùng trên một nhóm máy chủ nhỏ. Bảo mật và dễ quản lý là cao trong danh sách ưu tiên của tôi.
Các tính năng chính của nó là dễ dàng quản lý quyền SSH thông qua thành viên nhóm Unix, có các quyền được xác định chặt chẽ và được bảo mật theo mặc định.
Đang cài đặt
Cài đặt phần mềm (tùy chọn nhưng hữu ích):
yum install members # or apt install members
Thêm nhóm:
addgroup --system allowssh
addgroup --system sftponly
Trong /etc/ssh/sshd_config, đảm bảo rằng các cài đặt sau đây là No:
PermitRootLogin no
PubkeyAuthentication no
PasswordAuthentication no
Và vào cuối /etc/ssh/sshd_config, thêm hai khổ thơ này:
Match Group allowssh
PubkeyAuthentication yes
Match Group sftponly
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
(đừng quên khởi động lại SSH sau khi chỉnh sửa tệp)
Giải trình
Vì vậy, tất cả những điều này làm gì?
- Nó luôn vô hiệu hóa đăng nhập gốc, như một biện pháp bảo mật bổ sung.
- Nó luôn vô hiệu hóa đăng nhập dựa trên mật khẩu (mật khẩu yếu là rủi ro lớn cho các máy chủ chạy sshd).
- Nó chỉ cho phép đăng nhập (pubkey) cho người dùng trong
allowsshnhóm.
- Người dùng trong
sftponlynhóm không thể nhận được vỏ qua SSH, chỉ SFTP.
Việc quản lý người có quyền truy cập sau đó được thực hiện đơn giản bằng cách quản lý thành viên nhóm (những thay đổi này có hiệu lực ngay lập tức, không yêu cầu khởi động lại SSH):
# adduser marcelm allowssh
# members allowssh
marcelm
# deluser marcelm allowssh
# members allowssh
#
Lưu ý rằng người dùng sftp của bạn cần phải là thành viên của cả hai sftponly(để đảm bảo họ sẽ không nhận được vỏ) và allowssh(để cho phép đăng nhập ở vị trí đầu tiên).
Thêm thông tin
Xin lưu ý rằng cấu hình này không cho phép đăng nhập mật khẩu ; tất cả các tài khoản cần sử dụng xác thực khóa công khai. Đây có lẽ là chiến thắng bảo mật lớn nhất mà bạn có thể nhận được với SSH, vì vậy tôi cho rằng nó đáng để nỗ lực ngay cả khi bạn phải bắt đầu ngay bây giờ.
Nếu bạn thực sự không muốn điều này, thì hãy thêm PasswordAuthentication yesvào khổ Match Group allowsshthơ. Điều này sẽ cho phép cả pubkey và mật khẩu auth cho allowsshngười dùng.
Cấu hình này giới hạn bất kỳ sftponlyngười dùng vào thư mục nhà của họ. Nếu bạn không muốn điều đó, hãy xóa ChrootDirectory %hchỉ thị.
Nếu bạn làm muốn chroot để làm việc, điều quan trọng là thư mục home của người dùng (và bất kỳ thư mục trên nó) được sở hữu bởi root:rootvà không ghi được bởi nhóm / khác. Không có vấn đề gì khi các thư mục con của thư mục chính thuộc sở hữu của người dùng và / hoặc có thể ghi.
Có, thư mục chính của người dùng phải thuộc sở hữu gốc và không thể chấp nhận được đối với người dùng. Đáng buồn thay, có những lý do tốt cho giới hạn này. Tùy thuộc vào tình huống của bạn, ChrootDirectory /homecó thể là một lựa chọn tốt.
Đặt shell của sftponlyngười dùng /sbin/nologinlà không cần thiết cũng không gây hại cho giải pháp này, vì SSH ForceCommand internal-sftpghi đè lên trình bao của người dùng.
Việc sử dụng /sbin/nologincó thể hữu ích để ngăn chặn họ đăng nhập thông qua các cách khác (bảng điều khiển vật lý, samba, v.v.).
Thiết lập này không cho phép rootđăng nhập trực tiếp qua SSH; điều này tạo thành một lớp bảo mật bổ sung. Nếu bạn thực sự làm cần đăng nhập root trực tiếp, thay đổi PermitRootLoginchỉ thị. Cân nhắc đặt nó thành forced-commands-only, prohibit-passwordvà (như là phương sách cuối cùng) yes.
Đối với các điểm thưởng, hãy xem việc hạn chế ai có thể suroot; thêm một nhóm hệ thống gọi là wheel, và thêm / kích hoạt auth required pam_wheel.sotrong /etc/pam.d/su.