Using Net::SSH Ruby library to remote command execution that requires sudo su - another user

Question

My environment is configured with SSH password-less authentication for the user "master" between a node Server (Rundeck server) and node Target (remote Solaris host).

On Target, I want to execute a script /app/acme/stopApp.sh with the user appmanager.

Normally, when I need to run the script manually, I use:

ssh master@server sudo su - appmanager

or simply:

ssh -t master@server 'sudo su - appmanager'

which works without the password and finally run (as appmanager):

/app/acme/stopApp.sh

But I'm unable to figure out how to reproduce these steps using Net::SSH. When I execute sudo su - appmanager and then /app/acme/stopApp.sh, I'm doing it in a sub-shell, right?

require 'rubygems'
require 'net/ssh'
require 'net/scp'
require 'crypt/blowfish'
require 'yaml'

#
# ...
#

Net::SSH.start( host, user, :password => password ) do |session|

  # It's possible to proceed in this way?
  cmd = 'sudo su - appmanager;/app/acme/stopApp.sh'  
  ses = session.exec!( cmd )

end

I realized that if I try to execute something like I'm on the Target server:

sudo su -c /app/acme/stopApp.sh appmanager

I receive the message below:

We trust you have received the usual lecture from the local System Administrator. 

It usually boils down to these three things: 

 #1) Respect the privacy of others. 
 #2) Think before you type. 
 #3) With great power comes great responsibility. Password:

Password:

Answer 1

This is a bit of a sysadmin-y answer, but I think you are authenticating twice: once to log in as "master" (using master's keypair) and then a second time "master" sudo-ing the su to "appmanager" but using a password (hence the "lecture" message). But I think you're not answering the password challenge the second time. There are a few ways to get around this that come to mind:

1) Login as appmanager directly using that account's keypair. If you're worried about the security of the appmanager account, you can restrict ssh remote commands among other things.

2) As master, call a binary (not a script!) that is setuid as "appmanager" that simply calls the stopApp.sh script. An example.

3) Set the appropriate group that master is in to NOPASSWD in /etc/sudoers.