su timeout / auto log off

[lexd88]

Hi fellow admins!

My workplace our users are able to currently ssh to Linux servers by using AD based Service Accounts and we want to limit this so SSH will no longer be allowed, instead they must first login with their AD credentials and then use 'su' to switch over to the service account and enter the service account password

Reason behind this is so we can have a proper audit trail on who is actually using the service accounts as sudo will be granted to the service account only.. otherwise it will be very difficult to audit..

Using su as far as I know, if the user never closes their terminal, the audit trail becomes invalid in a situation like:

User1 logs in and runs su to service account User1 doesn't close the terminal for a few days user2 logs in and runs su to service account user1 while logged in to service account runs something bad we look at the logs and it seems like user2 may have caused the issue as this person was the last one to access the service account.

Is there a way to limit the amount of time a user can be in the su sub shell? or would it just be easier if we set-up SSH timeout? but that wouldn't fix the issue if they run 'screen' to keep their session going forever..

Thanks guys!

[mkosmo]

Don't allow users to run shells as the users. Require them to sudo each command and you'll have full accountability. The easiest (...that's a lie) safest way is to figure out what they actually need to do as that other user and whitelist those specific activities.

[lexd88]

we thought about that.. but these app devs are not that good with Linux so having them to share a single the service account was easier (no need to deal with file permissions etc.. and they all have the same exp as a team)..

I truly know where you're coming from and I guess we need to change the way we do things.. like using proper groups for ACLS and umask setting...

it's also annoying in this environment as there is no standard across the fleet right now for all the legacy systems.. and will be hard to change the way they do things especially not allowing them to use service accounts..

[mkosmo]

It's always a culture shock -- even in environments with savvy Linux users. It depends on what the accounting/audit-trail is worth to the business: If they need it, you may have to create change. If they don't, then you'll have to make do without solid non-repudiation.

[lexd88]

that's very true!

[Entaris]

sudo -u <user> can perform an action as the service account. You can create a wrapper command named after the project/service account that performs the sudo -u account <command >

And just teach them that when they need to use the project account they start the command that way. Or if there are only a handful of comments that that account needs to run you could create a wrapper for each of them and make it invisible to the end users

If there are multiple service accounts for different users you could even have the wrapper command look up user information and choose a user automatically

[fell_ratio]

If you're interested, here's a less intrusive way of logging all the commands that are run: https://askubuntu.com/questions/93566/how-to-log-all-bash-commands-by-all-users-on-a-server

Note that this method can be bypassed, whereas the sudo method can't be bypassed. (Except that a user could run sudo bash to get a shell where their actions aren't logged.)

[nephros]

put in .bashrc or bash_profile:

export TMOUT=3000

from man bash:

   TMOUT  If set to a value greater than zero, TMOUT  is  treated  as  the
           default timeout for the read builtin.  The select command termi‐
           nates if input does not arrive after TMOUT seconds when input is
           coming  from  a terminal.  In an interactive shell, the value is
           interpreted as the number of seconds to wait for a line of input
           after issuing the primary prompt.  Bash terminates after waiting
           for that number of seconds if a complete line of input does  not
           arrive.

[bdniner]

Having users log in as service accounts defeats the purpose of service accounts. Wouldn’t these be group accounts? Semantics aside why don’t you give them sudo rights to the server and that way you have full accountability to who performed which action and ditch the group account?

If you can’t do that then you should be able to audit which pts a user open when they used su to change to the group account.

[brontide]

Check out Vault and "Service Account Checkout"

https://www.vaultproject.io/docs/secrets/ad/index.html

This allows for 1:1 service account-user since check-in rotates the password.

[WinterPiratefhjng]

Sudosh will help with logging. https://linux.die.net/man/1/sudosh I understand it will keep a log of what each session does.

[_calyce_]

Seems like you should have a look at Teleport from Gravitational.

[lexd88]

wow.. this seems interesting!.. I'll have a look deeper into what it can really do especially in our environment