Tôi không có đủ đại diện để nhận xét về câu trả lời của Legate, nhưng tôi muốn chia sẻ rằng câu trả lời này đã giúp chúng tôi với một trường hợp sử dụng khác:
1.) tài khoản được đề cập là tài khoản dịch vụ cục bộ đang chạy ứng dụng, không phải tài khoản người dùng cuối.
2.) người dùng cuối ssh in chính họ, và sudo /bin/su <user>để trở thành người dùng và quản trị ứng dụng do yêu cầu theo dõi kiểm toán mà tài khoản dịch vụ không thể có khả năng đăng nhập trực tiếp.
3.) tài khoản dịch vụ phải có một lớp vỏ hợp lệ ( /bin/bashkhông /sbin/nologin), bởi vì một Scheduling Platform Enterprise (đại lý chạy như là người chủ địa phương) phải có khả năng su - <user>và không có su -s /bin/bash <user>khả năng rằng một vỏ đầy đủ không, và là cần thiết để chạy các công việc từ xa cho các hoạt động hàng loạt lớn hơn bao gồm nhiều máy chủ và cơ sở dữ liệu.
Vì vậy, ...
passwd -l <user>
Không thỏa mãn các ràng buộc vì xác thực khóa chung bỏ qua PAM và vẫn cho phép đăng nhập trực tiếp.
usermod -s /sbin/nologin <user>
Không thỏa mãn các ràng buộc bởi vì trình lập lịch biểu doanh nghiệp
usermod --lock --expiredate 1970-01-01 <user>
Đây là người chiến thắng của chúng tôi. Đăng nhập từ xa bị vô hiệu hóa, nhưng root vẫn có thể su <user>, như những người dùng khác có thể thông qua sudođể các trình lập lịch hoạt động đúng và người dùng cuối được ủy quyền có thể trở thành tài khoản dịch vụ đích khi cần.
Cảm ơn bạn cho giải pháp!