Home / server / Questions / 347102
Accepted
Sama
Asked: 2012-01-06 12:48:34 +0800 CST

Linux: ssh to host and use sudo to run a script, runs but part of script fails

  • 772

I've searched high and low for an answer to this. I have keys setup so no password is needed for the ssh into remote host. I have sudo set up with that user so that I can run the needed commands as root with no password. I've only been using ssh to execute remote commands for a few days (what a glorious discovery!).

A little background: The script that's being run on the remote host is a typical start/stop script for a program. Somewhere in the actual program, a log file is opened for writing. On the remote host, all is well if I run the script as root. If I run it as a user, I get an error: log4cplus:ERROR Unable to open file: appname.log. Makes sense, since the log is owned by root.

Now, the situation: I have a script on my local host that will ssh into the remote host and using sudo will run that script. The script is able to run. However, after it starts, I get that same error as above about the log file. I've tried the following, which all successfully run the script, but get the error. I know some aren't necessary, but I wanted to cover ALL bases that I could find (I tried with -t as well, but no difference. I wouldn't think there WOULD be, but...):

/usr/bin/ssh username@remotehost sh -c sudo "/etc/rc3.d/S99script start"

/usr/bin/ssh username@remotehost sh -c sudo "/etc/rc3.d/S99script start"

/usr/bin/ssh username@remotehost 'sh -c sudo "/etc/rc3.d/S99script start"'

/usr/bin/ssh username@remotehost sudo /etc/rc3.d/S99script start

/usr/bin/ssh username@remotehost "sudo /etc/rc3.d/S99script start"

/usr/bin/ssh username@remotehost sudo "/etc/rc3.d/S99script start"

/usr/bin/ssh username@remotehost 'sudo "/etc/rc3.d/S99script start"'

/usr/bin/ssh username@remotehost sudo su - -c "/etc/rc3.d/S99script start"

/usr/bin/ssh username@remotehost 'sudo su - -c "/etc/rc3.d/S99script start"'

I know there are other things I tried, but I didn't document them all. Don't laugh at my trying all the different quotes, I have a decent understanding of when to use which in general, but I wasn't taking any changes in trying different things :)

Something I noticed when running these, is if I do a ps -ef|grep for the script name, it shows the following:

[username's UID]  3070  3069  0 14:42 ?   00:00:00 bash -c /etc/rc3.d/S99script start

That's even for the ones where I do "sh -c sudo". The fact that it's running as bash -c is interesting, but also interesting (I thought?) is that it has the user's UID instead of username listed.

**Add: I also tried creating a script in "username"'s home directory that just does: sudo /etc/rc3.d/S99script start And I get the same result.

scripting ssh sudo

2 Answers

  1. You are making this too complicated. ssh -t user@host sudo /path/to/command should be all you need to do (no funky quoting, escaping, running su and sub-shells -- just the command exactly as you would type it on the remote end if you were running it manually).
    If you start using more complicated commands you may have to get into quoting and escaping, but for something this simple it's not necessary.

    Note that the -t flag for SSH is necessary if you need to enter a password for sudo: by default SSH will not allocate a tty for a remote-command session (sudo will complain bitterly about not being able to get your password). -t forces a terminal to be allocated so sudo has something to interact with.
    It may not be required in your case, but really won't hurt anything.

    • 4
  2. Best Answer

    first off, change your key-based auth such that your login to the remote system is as the user in question - then there's no need to use sudo (since you already indicated the service isn't running as root, there should be no security concerns with automated key-based logins).

    secondly, have a look at ForceCommand in sshd_config(5) - this provides extra security if you're working with a service account that should only be able to do one thing. Note well the reference to the Match directive.

    finally, sudo can have unexpected results when executing commands that also involve modification of files on the system - this is why things like "sudo echo foobar >> /etc/passwd" don't work the way you'd think they would. This is likely (although I can't be sure without seeing the actual script in question) a factor in your current situation. follow my first suggestion above and you'll bypass this issue entirely. :)

    • 0