Ich habe nicht genügend Repräsentanten, um die Antwort von Legate zu kommentieren, aber ich wollte mitteilen, dass diese Antwort uns bei einem anderen Anwendungsfall geholfen hat:
1.) Bei dem betreffenden Konto handelt es sich um ein lokales Dienstkonto, auf dem eine Anwendung ausgeführt wird, und nicht um ein Endbenutzerkonto.
2.) Endbenutzer ssh in sich selbst und sudo /bin/su <user>
um Benutzer zu werden und die Anwendung aufgrund einer Audit-Trail-Anforderung zu verwalten, dass das Dienstkonto keine direkte Anmeldefähigkeit haben kann.
3.) Das Dienstkonto muss eine gültige Shell haben ( /bin/bash
nicht /sbin/nologin
), da eine Enterprise Scheduling Platform (Agent wird lokal als Root ausgeführt) in der Lage su - <user>
und nicht in der su -s /bin/bash <user>
Lage sein muss, dass eine vollständige Shell funktioniert, und Jobs remote ausgeführt werden müssen für größere Batch-Vorgänge, die mehrere Server und Datenbanken umfassen.
Also ...
passwd -l <user>
Erfüllt keine Einschränkungen, da die Authentifizierung mit öffentlichem Schlüssel PAM umgeht und dennoch die direkte Anmeldung ermöglicht.
usermod -s /sbin/nologin <user>
Erfüllt keine Einschränkungen, da der Unternehmens-Scheduler abbricht
usermod --lock --expiredate 1970-01-01 <user>
Das ist unser Gewinner. Die Remote-Anmeldung ist deaktiviert, Root kann sie jedoch weiterhin ausführen su <user>
, ebenso wie andere Benutzer über, sudo
damit der Scheduler ordnungsgemäß funktioniert und berechtigte Endbenutzer bei Bedarf das Zieldienstkonto werden können.
Danke für die Lösung!