Nie mam wystarczającego przedstawiciela, aby skomentować odpowiedź Legate, ale chciałem się podzielić, że ta odpowiedź pomogła nam w innym przypadku użycia:
1.) konto, o którym mowa, to konto usługi lokalnej działające na aplikacji, a nie konto użytkownika końcowego.
2.) użytkownicy końcowi ssh jako sami oraz sudo /bin/su <user>aby zostać użytkownikiem i administrować aplikacją z powodu wymogu ścieżki audytu, że konto usługi nie może mieć możliwości bezpośredniego logowania.
3.) konto usługi musi mieć poprawną powłokę ( /bin/bash, nie /sbin/nologin), ponieważ platforma planowania przedsiębiorstwa (agent działa lokalnie jako root) musi mieć możliwość pełnienia powłoki su - <user>i nie ma su -s /bin/bash <user>możliwości działania takiej powłoki i jest potrzebna do zdalnego uruchamiania zadań dla większych operacji wsadowych, które obejmują wiele serwerów i baz danych.
Więc ...
passwd -l <user>
Nie spełnia ograniczeń, ponieważ uwierzytelnianie za pomocą klucza publicznego omija PAM i nadal umożliwia bezpośrednie logowanie.
usermod -s /sbin/nologin <user>
Nie spełnia ograniczeń, ponieważ psuje harmonogram w przedsiębiorstwie
usermod --lock --expiredate 1970-01-01 <user>
To jest nasz zwycięzca. Zdalne logowanie wyłączone, ale root może nadal su <user>, podobnie jak inni użytkownicy, dzięki sudoczemu harmonogram działa poprawnie, a autoryzowani użytkownicy końcowi mogą w razie potrzeby zostać docelowymi kontami usług.
Dziękuję za rozwiązanie!