We have a handful of batch accounts that run our production jobs. Our users are able to use sudo to become that account. Also, because of other reasons, the passwords are also listed in an encrypted file that each team can see their batch ID. So, I have some users that feel it is ok to su - $ID. Then, what happens is that they forget the password an lock out the account therefore causing production processing to stop. Our servers are HPUX, and my thought was that I could put an administrative lock on the accounts (passwd -l). That works and will prevent anybody from logging into via a new shell session or from a command prompt typing su - $ID. We are working towards a situation that will allow that the users not know the password...however they could still su - $ID 3 times and lock the acct out. My catch 22 is that these batch accounts need to ssh (using shared ssh keys) between servers. doing the admin lock prevents that. Any ideas?
Have you ever taught about disabling the policy that locks the account after 3 failed login attamps using strong password instead. The situation you discribe is a kind of DOS Attack and you pay the price for slightly improved security with a major decline of availability.
I'm not shure what happen when U set the login shell of the involved accouts to /bin/false.
this will definetely prevent from logging in via su but background jobs should commonly be able run as expected.
company policy has us lock out at 3 incorrect attempts. /bin/false would work except that these batch IDs also need to ssh between servers. each batch acct exists on 6 different servers. we are able to ssh, scp, etc. between them without any authentication. if I set the shell to /bin/false then ssh'ing to the other server will immediate end the session on the remote server.
I dont know...
I usually use sudo for these account and give the permissions to users to su - batch account with no passwd.. and I am the only one who know them and when I forget I change them... Like that there is no fuss no one has the passwd except myself...
since these accounts are for batches, there shouldnt be interactive shell, and so only users doing su - will read the .profile, I would take that opportunity to modify the .profile so it saves a .sh_history for each of the people that can su - while logging also date-time on connection and from where (tty or IP), because what is stopping the user to type passwd? (maybe not realizing in multi windoing he is in the wrong one...) and changing the passwd...
Even though the accounts are not directly logging in, they still need to login and hence cannot be set to /bin/false or /bin/nologin.
The only thing I can think of is to have users execute batch files from some other system. The batch file connects to your prod servers using only SSH keys and do what ever they have to do.
That way users don't have to 'su' on your Production and accidentally lock up the accounts.
Use SSH keys. You can even restrict IP or hostname access with these keys.
P.S. I would tell users to stop 'su' if they are not sure about the password first time...
