Forum: Ruby Can't run sudo under ssh.exec!

Hi,

The problem is, when I'm trying to run ssh.exec!("sudo
/home/cder/ComponentTester/JKL") its simply hangs in the server, firs I
thought it is because I haven't passed a sudo's password nevertheless it
is still the same. Is there a way to execute sudo and avoid any hangs if
so how to do it and which articles should I look through or it will be
great to have any tutorials for this subject. Many thanks :)

On Wed, Mar 20, 2013 at 1:02 PM, Tim Ash <lists@ruby-forum.com> wrote:

> The problem is, when I'm trying to run ssh.exec!("sudo
> /home/cder/ComponentTester/JKL") its simply hangs in the server, firs I
> thought it is because I haven't passed a sudo's password nevertheless it
> is still the same. Is there a way to execute sudo and avoid any hangs if
> so how to do it and which articles should I look through or it will be
> great to have any tutorials for this subject. Many thanks :)

You can configure sudo in a way as to permit some commands without
password.  You could as well log in the with the target user and avoid
sudo altogether, couldn't you?

Cheers

robert

Thank you for your reply, it is suitable to do not change any thing in 
the server side, and the executable which I want to execute through 
ssh.exec shouting that need's sudo's permitting. Maybe my thinking could 
be wrong as I'm beginner, but it would be great if you can suggest 
anything strait-forward to get it done.

On Wed, Mar 20, 2013 at 1:19 PM, Tim Ash <lists@ruby-forum.com> wrote:
> Thank you for your reply, it is suitable to do not change any thing in
> the server side,

Why?  Obviously you placed /home/cder/ComponentTester/JKL there so you
*did* change the server already.

> and the executable which I want to execute through
> ssh.exec shouting that need's sudo's permitting. Maybe my thinking could
> be wrong as I'm beginner, but it would be great if you can suggest
> anything strait-forward to get it done.

I'm at a loss at the moment.  Maybe you can use #expect to react to
the password prompt and send the password over.

Cheers

robert

Tim Ash wrote in post #1102437:
> it is suitable to do not change any thing in
> the server side

Maybe you can elaborate on what it is you're willing/able to change and 
not change.  Use of sudo itself requires changes (editing of the sudoers 
file).  If you've already done this, then I don't see why you can't use 
the NOPASSWD keyword in it (though I wouldn't recommend it). 
Alternatively you can pass the password to sudo on the command line via 
echo <password> | sudo -S <command>

Only problem with that is that then the password would be in the shell
history file. Better to either use the sudoers or ln -s the history file 
to
/dev/null

D. Deryl Downey wrote in post #1103052:
> Only problem with that is that then the password would be in the shell
> history file. Better to either use the sudoers or ln -s the history file
> to
> /dev/null
You're absolutely right, which is why I don't recommend either solution 
which I should have been more explicit about.   A symlink is a great 
work around too, or if history usage was still desired, cat /dev/null > 
~/.bash_history could serve as well.

Hi Tim,

On 20/03/13 22:49, Tim Ash wrote:
> Thank you for your reply, it is suitable to do not change any thing in
> the server side, and the executable which I want to execute through
> ssh.exec shouting that need's sudo's permitting. Maybe my thinking could
> be wrong as I'm beginner, but it would be great if you can suggest
> anything strait-forward to get it done.

The most straightforward solution is to explore the sudo/sudoers route
as suggested, and add a rule that will allow the command you need. It'll
save you a lot of hassle.

If you really, really can't go this way, the options aren't that
straightforward any more. Some possibilities are:

- Use IO.popen to run ssh, and then push the password down the pipe,
followed by the command. You'll have to experiment to figure out the
specifics though, as well as the best way to keep track of the password.

- Explore the use of ssh to allow passwordless access to the target
account, perhaps through a private/public key pair.

- Write a script that runs on the target account that checks, every few
seconds, for the presence of some lock file, or alternatively, create a
server that sits there, waiting for connections. Your ssh command can
hen trip that lock file, or connect to the server, to indicate you wish
to run something.

These really are second-rate solutions compared to setting up sudo to
accept the single command in the first place. They'll take a lot of
extra work. I suggest you fully explore the sudoers route first if it is
at all an option.

Good luck.

Cheers,
Garth