Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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??)

UPDATE#2:

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"

share|improve this question
    
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. –  Michael Hampton Apr 24 '13 at 21:50
add comment

5 Answers

up vote 0 down vote accepted

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.

share|improve this answer
    
I hope this is true :D –  gasko peter Apr 29 '13 at 15:59
add comment

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

share|improve this answer
add comment

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

share|improve this answer
    
Can ex.: fabric handle that the servers has different passwords when using sudo?? –  gasko peter Apr 29 '13 at 15:56
    
this could be the solution too :) –  gasko peter Apr 29 '13 at 16:00
add comment

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.

admin ALL=NOPASSWD:ALL

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.

share|improve this answer
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
add comment

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.

share|improve this answer
    
Remote control a machine(s) with ad-hoc commands –  gasko peter May 9 '13 at 6:09
add comment

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.