У мене немає достатнього представника, щоб прокоментувати відповідь Legate, але я хотів поділитися, що ця відповідь допомогла нам у іншому випадку використання:
1.) обліковий запис - це локальний обліковий запис служби, на якому працює програма, а не обліковий запис кінцевого користувача.
2.) кінцеві користувачі ssh у себе, а sudo /bin/su <user>також стати користувачем і адмініструвати додаток через вимогу аудиторської перевірки, що обліковий запис служби не може мати можливість прямого входу.
3.) В обліковому записі служби повинна бути дійсна оболонка ( /bin/bashне є /sbin/nologin), тому що платформа планування підприємства (агент запускається як root локально) повинна бути здатна su - <user>і не мати su -s /bin/bash <user>можливості, яку робить повна оболонка, і потрібна для віддаленого запуску завдань. для більших пакетних операцій, що охоплюють декілька серверів та баз даних.
Отже ...
passwd -l <user>
Не задовольняє обмежень, оскільки автентифікація відкритого ключа обходить PAM і все ще дозволяє прямий вхід.
usermod -s /sbin/nologin <user>
Не відповідає обмеженням, оскільки порушує планувальник роботи підприємства
usermod --lock --expiredate 1970-01-01 <user>
Це наш переможець. Віддалений вхід увімкнено, але root все ще може su <user>, як і інші користувачі, завдяки sudoчому планувальник функціонує належним чином, а авторизовані кінцеві користувачі можуть стати необхідним обліковим записом служби.
Дякую за рішення!