Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
1  
Why not fix the root cause instead? Give the user that the service is running as permission to write to its log file; maybe use logrotate to make sure that it's not growing infinitely while creating the file after rotation with the correct permissions? –  Shane Madden Jan 5 '12 at 20:59
    
D'oh! I thought it was running as root (that would be awful, but don't get me started on the software (not homegrown)). It's running as a service account for the program. That confuses me even more, though -- I guess my root question, then, is: Why would running the script as root work, but running it via sudo not work? –  Sama Jan 5 '12 at 21:15
    
Could you post your sudoers file? –  Hubert Kario Jan 5 '12 at 21:21
    
I originally had it more specific, but in the interest of troubleshooting I changed it to: username ALL=(ALL) NOPASSWD: ALL (and I did it with visudo, not by vi /etc/sudoers) –  Sama Jan 5 '12 at 21:24
1  
If the S99script script happens to be bash I would be tempted to temporarily add a set -x as the first command after the shebang line. Perhaps with a more verbose output what is broken will be more obvious. Perhaps something about the environment isn't right? –  Zoredache Jan 5 '12 at 22:25

2 Answers 2

up vote 0 down vote accepted

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. :)

share|improve this answer
    
This worked, Scott... thanks! That will do for now, but still would like to figure out how to do it without logging in as the service account. Much appreciated. –  Sama Jan 5 '12 at 22:03
1  
there's significant value in separating tasks such that your service accounts run the tasks specific to the service, rather than running it as other users. I agree that it would be good to know specifically why sudo was failing, but aside from that, using dedicated accounts to run individual services is a best practice. (see for example the history of OpenBSD's /etc/passwd: openbsd.org/cgi-bin/cvsweb/src/etc/master.passwd) –  darkuncle Jan 5 '12 at 23:31
    
Much agreed. Solution found above. In this case, the purpose of the script I wrote is to check if a certain process is running and restart it and notify if not. (It's much more eloquent than just that, though.) The server the process in question is running on is stripped down and doesn't have mail, nail, snmp, etc on it, thus why I'm doing this from a separate server in the first place. Do you think for this sort of purpose in general it's wiser to use the service account directly, rather than a separate admin account to invoke? Thanks! –  Sama Jan 5 '12 at 23:43
1  
for managing services on a small scale, it makes sense to use the per-service account to limit your exposure security-wise. If you're talking about doing this on a bigger scale, that kind of thing can get unmanageable quickly (and you're probably looking at some kind of config mgmt system like puppet or chef or capistrano or etc. anyway - see also infrastructures.org). I think what you're doing (using a central, internal, secured admin host to reach out and manage other hosts) makes sense; using key-based SSH to a service acct. seems like a good way to do it. –  darkuncle Jan 6 '12 at 16:36
    
Thanks Scott, that definitely makes sense. Also appreciate the link, I haven't stumbled across (I avoided the pun) that before. –  Sama Jan 6 '12 at 20:26

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.

share|improve this answer
    
The "-t" option is most probably the key to the solution. On some distributions an allocated TTY is required for sudo-operations. If a single "-t" does not help, use "-tt". I think I had the same problem on CentOS 5. –  Nils Jan 5 '12 at 21:20
    
I think I had tried that, Nils, but I just tried it again and nada. Thanks though. –  Sama Jan 5 '12 at 21:22
    
@Sama what happens when you do ssh -t user@host sudo whoami ? It sounds like sudo isn't changing your UID... –  voretaq7 Jan 5 '12 at 21:33
    
It showed root. I then put that into a new script and ran it and it also reported back root. (I did echo `ssh -t user@host sudo whoami`) –  Sama Jan 5 '12 at 22:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.