Hi all,

I have a situation where I have a shell script that I need to run remotely on multiple *nix machines via SSH. Unfortunately, some of the commands in it require root access. I know that best practices for ssh entail configuring it so that the root account cannot log in, you need to elevate to root via su after logging in with a regular account.

Unfortunately, this seems to leave me in a dilemma: How in a script can I elevate to root, since it will prompt me for a password that I will not be there to enter? Or, is there some other alternative from an advanced security perspective that will allow me to log in with an account that has root level access to the machine (but isn't the actual "root" account)?

Finally, just to head this off: No, I cannot set the script up in crontab to run as root at a certain time/frequency. The requirements for this script to run is: 1) SCP it to /var/tmp; 2) Execute via SSH as root or root-equivalent; 3) scrape the output; 4) Execute "rm /var/tmp/script.sh" via SSH to remove it.

Any suggestions?

Are the privs required related to file access?

Try adding an account that can newgrp to the root, bin, adm, mail or whatever group it requires to get into the files in question.

Unfortunately I already tried this, and at least with one utility (ioscan on HP-UX), adding the group the utility was in did not help, and adding the group assigned to the block device it was trying to read from also did nothing. In fact, documentation I found for ioscan stated it had to be run as root. (I realize this is getting HP-UX specific at this point, but I know I had this problem with some Linux commands as well -- I believe that lshal can only be run as root per it's documentation)

You are probably stuck with having to do this manually, if you don't want to compromise security.

One other poor choice - write a daemon - one that runs as root. Write the temp script to a protected directory via scp. Have the daemon run the script when it sees it out there, delete it, then email the output to you.

Can you push back on the limitations - like no crontab? You can always explain to mgt that you may be out days when this has to run. The reason I say this - it sounds like an arbitrary decision somewhere upstream.

Another compromise could be to create a new user with no password (but a valid shell and home directory), and use sudo to run the commands that need to be run as root. The user will have to be added to the /etc/sudoers file (using visudo or editsudo) and fine grain control can be used here to limit the commands that need to be run.
Then you will need to set up ssh keys for the user running the admin script and the new users you have created, so that they can ssh in without a password prompt.