OpenSSH plugin and sudo support

[Russ Robinson]

Has anyone gotten the OpenSSH plugin to also support sudo (with password prompt) to work with remote commands?  Our basic workflow is the command would ssh as the user's personal userid and password (captured by the options in the job), step would ssh to the target node, sudo su over to target Linux userid (answering the sudo password prompt with the same password captured in the job options), and run a command.

[rac...@rundeck.com]

Hi Russ,

Based on this and this, I did a working sudo example using OpenSSH node executor with username/password options.

Node definition:

<?xml version="1.0" encoding="UTF-8"?>
<project>
  <node name="node00" 
  description="Node 00" 
  tags="user" 
  hostname="192.168.33.20" 
  osArch="amd64" 
  osFamily="unix" 
  osName="Linux" 
  osVersion="3.10.0-1062.4.1.el7.x86_64" 
  username="${option.username}"  
  node-executor="ssh-exec" 
  file-copier="ssh-copier"  
  ssh-authentication="password" 
  ssh-password-option="option.password"
  ssh-options="-o ConnectTimeout=5000"
  sudo-command-enabled="true"
  sudo-password-option="option.password"/>
</project>

And this job definition example:

<joblist>
  <job>
    <context>
      <options preserveOrder='true'>
        <option name='password' secure='true' />
        <option name='username' value='vagrant' />
      </options>
    </context>
    <defaultTab>nodes</defaultTab>
    <description></description>
    <dispatch>
      <excludePrecedence>true</excludePrecedence>
      <keepgoing>false</keepgoing>
      <rankOrder>ascending</rankOrder>
      <successOnEmptyNodeFilter>false</successOnEmptyNodeFilter>
      <threadcount>1</threadcount>
    </dispatch>
    <executionEnabled>true</executionEnabled>
    <id>b188c66c-c057-4bb7-98bf-7c84632bc144</id>
    <loglevel>INFO</loglevel>
    <name>SudoOpenSSH</name>
    <nodeFilterEditable>false</nodeFilterEditable>
    <nodefilters>
      <filter>name: node00</filter>
    </nodefilters>
    <nodesSelectedByDefault>true</nodesSelectedByDefault>
    <plugins />
    <scheduleEnabled>true</scheduleEnabled>
    <sequence keepgoing='false' strategy='node-first'>
      <command>
        <exec>whoami</exec>
      </command>
      <command>
        <exec>sudo cat /etc/shadow</exec>
      </command>
    </sequence>
    <uuid>b188c66c-c057-4bb7-98bf-7c84632bc144</uuid>
  </job>
</joblist>

Hope it helps!

​

[rac...@rundeck.com]

Sorry, the two links are this and this.

Regards.

[Kobi Rosenstein]

I'm not sure about the openssh plugin, but in general you don't need to actually switch user, you can run commands simply with sudo -u username command, which will run the command  as the given user.

You can also have your original user have sudoers entries that allow that user to run certain or all commands as sudo without a password.

On Feb 3 2021, at 5:00 am, Russ Robinson <eagl...@gmail.com> wrote:

Has anyone gotten the OpenSSH plugin to also support sudo (with password prompt) to work with remote commands?  Our basic workflow is the command would ssh as the user's personal userid and password (captured by the options in the job), step would ssh to the target node, sudo su over to target Linux userid (answering the sudo password prompt with the same password captured in the job options), and run a command.

--

You received this message because you are subscribed to the Google Groups "rundeck-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rundeck-discu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/rundeck-discuss/e61ec37a-5391-4395-b4cd-ef18c993597an%40googlegroups.com.

[Russ Robinson]

Yes - I know you can technically setup sudo in such a manner.  However, our security team will not allow password-less setup.

Thanks,

Russ

On Feb 4, 2021, at 2:08 AM, Kobi Rosenstein <kobiros...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/rundeck-discuss/88F5180D-29EE-44AA-B379-11A2FF71193B%40getmailspring.com.

[Russ Robinson]

Team,

  I'm still struggling with this.  Within my job, I have it just running a simple command: sudo -u root -i hostname

Within my project, I have the following settings:

project.always-set-pty=true
....
project.plugin.NodeExecutor.ssh-exec.authentication=password
project.plugin.NodeExecutor.ssh-exec.ssh_options=-o RequestTTY\=yes -o ServerAliveInterval\=10 -o TCPKeepAlive\=yes -o ConnectTimeout\=240
project.plugin.NodeExecutor.ssh-exec.ssh_password_option=option.sshPassword
project.ssh-authentication=privateKey
project.ssh-keypath=/var/lib/rundeck/.ssh/id_rsa
project.sudo-command-enabled=true
project.sudo-password-option=option.sshPassword
....
service.NodeExecutor.default.provider=ssh-exec

However my step within the job encounters the following error: "you must have a tty to run sudo".  The step before which runs just command "date" works fine.

Any suggestion of what I'm overlooking to get sudo to work with openssh plugin?

[rac...@rundeck.com]

Hi Russ,

In my previous post, I used an environment as Kobi described based on vagrant (in fact, testing again sudo worked with or without the specific sudo attributes, my bad).

Following this, the best approach is to use the default SSH node executor with a sudo configuration. Also, you can test with the new SSHJ node executor.

Greetings.

PD: Post edited. It seems that Google Groups has some problems with some links.

[Russ Robinson]

My reason for changing for default ssh is the need for keepalive so that long running processes are not ended by ssh timeouts.

Thanks,

Russ

On Apr 19, 2021, at 6:12 PM, rac...@rundeck.com <rac...@rundeck.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/rundeck-discuss/befad0be-c892-429f-864e-6da809feab0dn%40googlegroups.com.

[Russ Robinson]

I tried the newer sshj plugin.  It never answers the sudo prompt.  I have the following in my project definitions:

project.sudo-command-enabled=true
project.sudo-password-option=option.sshPassword

Suggestions?

[rac...@rundeck.com]

Hi Russ,

I tested using the SSHJ plugin.

1- I used a job with mypassword (to test the ssh password authentication) and sudoPassword (to test sudo) Secure Remote Authentication options:

<joblist>
  <job>
    <context>
      <options preserveOrder='true'>

        <option name='mypassword' secure='true' />
        <option name='sudoPassword' secure='true' />

      </options>
    </context>
    <defaultTab>nodes</defaultTab>
    <description></description>
    <dispatch>
      <excludePrecedence>true</excludePrecedence>
      <keepgoing>false</keepgoing>
      <rankOrder>ascending</rankOrder>
      <successOnEmptyNodeFilter>false</successOnEmptyNodeFilter>
      <threadcount>1</threadcount>
    </dispatch>
    <executionEnabled>true</executionEnabled>

    <id>03f28add-84f2-4013-b8f5-e48feaf5977c</id>
    <loglevel>INFO</loglevel>
    <name>HelloWorld</name>
    <nodeFilterEditable>false</nodeFilterEditable>
    <nodefilters>
      <filter>name: Centos</filter>

    </nodefilters>
    <nodesSelectedByDefault>true</nodesSelectedByDefault>
    <plugins />
    <scheduleEnabled>true</scheduleEnabled>
    <sequence keepgoing='false' strategy='node-first'>
      <command>

<exec>sudo cat /etc/shadow</exec>
      </command>
    </sequence>

    <uuid>03f28add-84f2-4013-b8f5-e48feaf5977c</uuid>
  </job>
</joblist>

The detail is that the sudo password option must be named sudoPassword (defined as Secure Remote Authentication option), with another name doesn’t work.

2- My node source:

Centos:
  nodename: centos
  hostname: 192.168.33.20
  description: centos 7
  username: test
  osFamily: unix
  node-executor: sshj-ssh
  file-copier: sshj-scp
  tags: centos
  ssh-authentication: password

3- I added these lines to the project.properties config:

project.sudo-command-enabled=true
project.sudo-password-option=option.sudoPassword
project.ssh-password-option=option.mypassword

Could you test in this way?

Hope it helps!

​

[Russ Robinson]

Okay.  I got that to work.  Some notes though.  I had to move the following from my project settings to node attribute.  Neither of the following project settings work with sshj plugin:

project.ssh.user=${option.username}

project.ssh.user=option.username

I had to move that to a node attribute of:

username=${option.username}

Since the Linux ssh password for the user is the same as the password used for their sudo access (and I did not want them to have to type their password multiple times); I changed the project settings to:

project.ssh-password-option=option.sudoPassword
project.sudo-command-enabled=true
project.sudo-password-option=option.sudoPassword

Is there a reason why project.ssh.user cannot be picked up in project settings?  Why is sudoPassword the hard-coded option value allowed (or are there plans to make it more flexible to allow any option)?

[Russ Robinson]

After looking at the code at https://github.com/rundeck-plugins/sshj-plugin/blob/main/src/main/java/com/plugin/sshjplugin/SSHJNodeExecutorPlugin.java , I see the following line:

public static final String NODE_ATTR_SUDO_PASSWORD_OPTION = "password-option";

Hence if I place the following in my node's definition:

"password-option": "option.sshPassword"

Sudo then works fine using the sshPassword option from the existing jobs.  Did someone mean to have:

public static final String NODE_ATTR_SUDO_PASSWORD_OPTION = "sudo-password-option";

In order to match up with the existing default Rundeck NodeExecutor plugin?

[rac...@rundeck.com]

Hi Russ,

Yeah, internally is the easiest way to pass that value without needing extra configurations and giving the possibility of having that data that changes at runtime, by design, the node executor expects that option specifically. Same on PywinRM on password-storage-path attribute.

Anyway, you can suggest using any other option here.

Regards!