set up pf a multi user site

What OS?

If Unix, make sure all are members of the staff group and all have same permissions

Hi Rick.

We are on linux (migrated from AIX) and work on the server.

We login to the server with our own account and use ‘sudo’ to change user to the code owner (hci) or runtime owner (hcimgr).

i.e.

 sudo su – hci

or

 sudo su – hcimgr

We ensure that our local accounts are in the same *nix group as the ‘hci*’ accounts.

The AIX smit (smitty users) should walk you through everything you need to setup a user.  Of course I would view the hci user to make sure you choose the right groups and privs.

Rob

Make sure “hci” owns all the Cloverleaf files.   We’ve had issues with the testing tool if one of the users (not hci) owns the Cloverleaf file.

Does anyone have more detailed instructions on how to set up sudo to access the hci account? I don’t want to give root access to all users, so the “sudo su – hci” command wouldn’t work. I was thinking of putting this in the sudoers file:

%staff    ALL=(hci) NOPASSWD: ALL

This would allow anyone in the staff group to login as hci.

The next problem that I have is that the .profile for the hci account isn’t being run. I’m trying to use “sudo -s -H -u hci” from my regular account. Our hci account uses “bash” as the login shell, and I think that bash isn’t reading the profile because it doesn’t think that it is being run as a login shell.

I think I figured out the .profile part: I need to run “sudo -i -u hci”.

We have everyone login to the *nix server as their own account and then use:

su – hci

that forces the *nix system to use the .profile of the hci user and not reference anything from the originating user.

The one issue doing this is that if you use the history commands, you can pull up commands that were done by other users.  We had someone pull up a remove command and run it in the wrong directory.  So I figured out a way to have each user that “su’s” to the hci account have their own history file.

Rob

We use the following to the .profile file for hci to ensure each user has their own history in Linux:

We have everyone login to the *nix server as their own account and then use:

su – hci

that forces the *nix system to use the .profile of the hci user and not reference anything from the originating user.

Do they have to type in the hci password? What prevents them from logging in as hci directly?

Also the “-i” option on sudo clears out the environment from the original user.

We have everyone login to the *nix server as their own account and then use:

su – hci

that forces the *nix system to use the .profile of the hci user and not reference anything from the originating user.

Do they have to type in the hci password? What prevents them from logging in as hci directly?

Also the “-i” option on sudo clears out the environment from the original user.

In our setup (AIX 6.1), the users do need to enter the hci password when they su up to the hci username.  We prevent them from logging in as hci directly by adding the following lines to /etc/ssh/sshd_config:

Match User hci

PasswordAuthentication no

That will not allow hci to login with a password, but still allow scripts which can handle key-file authentication (think sftp) to still work as an hci user.  That has satisfied our security team…so far

We prevent them from logging in as hci directly by adding the following lines to /etc/ssh/sshd_config:

Match User hci

PasswordAuthentication no

Yeah, I looked at doing that as well, but our version of SSHD (4.3p2) is too old and doesn’t support the Match keyword. Thanks for your suggestions.