hint (on client side, how to encrypt files/pwd's):

# encrypt pwd with ssh key: 
openssl rsa -in ~/.ssh/id_rsa -outform pem > ~/.ssh/TEMP-id_rsa.pem 2>/dev/null
openssl rsa -in ~/.ssh/id_rsa -pubout -outform pem > ~/.ssh/TEMP-id_rsa.pub.pem 2>/dev/null
echo $PWDHERE > ~/.ssh/TEMP.pwd
openssl rsautl -encrypt -pubin -inkey ~/.ssh/TEMP-id_rsa.pub.pem -in ~/.ssh/TEMP.pwd -out ~/.ssh/TEMP.pwd.enc 2>/dev/null
rm ~/.ssh/TEMP.pwd > /dev/null 2>&1

# decrypt: 
PWDHERE=`openssl rsautl -decrypt -inkey ~/.ssh/TEMP-id_rsa.pem -in ~/.ssh/TEMP.pwd.enc`

So.. it would be a very easy task to automate running commands via SSH on servers with the root user on server side (in the end we need to run a script from a desktop machine on server side with root user, but running a command automated would be enough to know, from there we could do the thing..).

BUT: the Question is that how to securely automate running commands with root if we have to "sudo su -" first on the server, and give password in it?

UPDATE: modifying the sudoers file is not an option. (maybe puppet can do this??)


echo myPassword | sudo -S ls /tmp

isn't secure AFAIK. (because if other users 'ps -ef' they could see the pwd for a little time?) So that's not a solution either.

UPDATE#3: I want to do "Remote control a machine(s) with ad-hoc commands"

  • Store passphrase in a file, then cat file | sudo -S ....
    – peterph
    Mar 26 '13 at 10:04
  • If you can't update the sudoers file, you can't really make this secure. Go fix that problem first. Apr 24 '13 at 21:50

This isn't the best way to do it. However, your approach does not have the defect you claim. When you run

echo myPassword | sudo -S ls /tmp

the password never appears as the argument of an external command: all shells out there (except for some installations of BusyBox — it depends on a compilation option) have echo built in.

  • I hope this is true :D Apr 29 '13 at 15:59

What you are trying to do is insecture in itself and really shouldn't be done.

In that light, maybe you want to rethink your requirements on "secure". Why on earth bother with sudo? You can set up a (second) SSH server which accepts login as root user, but with public key authentication only. That way you don't need to transmit passwords at all and just log in as user root and run your commands. You can simply

  • copy the config from your present ssh server, which is most likely stored under /etc/ssh/sshd_config,
  • modify it to
    • allow root login,
    • allow public key authentication,
    • deny password authentication,
    • make it listen on a different port, for example 666
  • start a new sshd instance making it use your new alternate config file using the -f option.

Then you set up public key authentication so that you can ssh root@server -p 666 "rm -rf /" from your desktop machine without the need for sudo and a password.

Good Riddance :-)


I actually use python fabric and capistrano. They're both fairly easy to learn and will make your life a lot easier.

  • Can ex.: fabric handle that the servers has different passwords when using sudo?? Apr 29 '13 at 15:56
  • this could be the solution too :) Apr 29 '13 at 16:00

It would be best to design your automation such that it's fired off from crontab on the server itself.

Another possibility is to create a setUID wrapper (which can just be something like a C program that calls execv("/path/to/script",argc,argv); or the like) for the root-required commands, and only allow your automation users to run it via group permissions, e.g.

chown root /usr/local/sbin/trustedWrapper
chmod 4750 /usr/local/bin/trustedWrapper
chgrp scriptrunners /usr/local/bin/trustedWrapper

As a last resort, configure sudo to not require a password for the user, by adding the NOPASSWD option to their sudoers entry, e.g.


although you should probably restrict the runnable programs list to only the ones that should be accessible via automation. For extra security, you will probably want to disable password logins for this user and ONLY allow login via ssh key.

  • 1
    Scripts can't be suid.
    – psusi
    Apr 30 '13 at 15:44
  • I knew that, but I brainfarted when I wrote the answer. Fixed, and also expanded a bit on what I meant by "wrapper," thanks.
    – fluffy
    Apr 30 '13 at 16:12

I think that's the wrong approach, what are you trying to do ?

Remote control a machine(s) with ad-hoc commands, then use something like csshx

Or Automatically have jobs run by root via cron, then just setup cron jobs on the server, the server doesn't depend on the client machine to login and kick off the job.

  • Remote control a machine(s) with ad-hoc commands May 9 '13 at 6:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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