sudo with automation-cli

No tricks, using an SSH connection, through which you execute a shell, just set sudo on the remote server as you wish, and add the -sudo switch to the “run” command. The shell will be executed in this mode.

If you need to pass a password, add the -sudopass “password value” switch.

In practice, passing passwords on the command line is strongly discouraged. The safest method is to set “sudo” on the remote server, so that it does not ask for a password, and to limit the scope of commands used to those specified in the operation. This gives you full control over what is done on the server.

A password can be intercepted by any means, and if the scope is not limited, the password will have served no useful purpose.

Limiting sudo access to a password is equivalent to giving root access to the user: sudo bash :)…

Preparing the sudo environment

On the remote host :

• Create a user account, add for this account :

  • The SSH public key linked to your “OPSDirectory” (~/.ssh/authorized_keys).
  • A password.

• Add this account to the “sudo” group (/etc/group).

From the control node in a new terminal, run :

ssh -i [ssh private key OPSDirectory] [user]@[ip|host name of remote server]
# If you're connected to the host, let's try a command requiring root privileges
sudo cat /etc/shadow
# shell asks for user password, enter password
# the shell displays the contents of /etc/shadow

Executing an operation with the sudo user password (bad practice)

From the control node, I assume the SSH private key is specified in an inventory file, run :

export OPS="$(pwd)" # or relative or absolute path OPSDirectory
automation-cli run -i "[inventory file]" -h "[ip|host name of remote server]:[SSH port(22)]:[user]" -c "cat /etc/shadow" -sudo -sudopass "[user password]"

The contents of the file are displayed, I repeat: This is a bad practice…

Executing an operation without the sudo user password

This requires a “sudo” setting on the administered node:

• 1st step:

  • Remove the user from the “sudo” group.
  • Edit the /etc/sudoers file with the visudo command, and add after the “root…” line: [user] ALL=(ALL) NOPASSWD: ALL
  • run :

  export OPS="$(pwd)" # or relative or absolute path OPSDirectory
  automation-cli run -i "[inventory file]" -h "[ip|host name of remote server]:[SSH port(22)]:[user]" -c "cat /etc/shadow" -sudo"

  The user no longer needs to provide his password, but still benefits from all the privileges linked to this sudo misconfiguration.

• 2nd step:

  • Delete the line previously added to the /etc/sudoers file
  • Create the “operation” group and add the user to this group (/etc/group)
  • indicate the commands allowed (can also be a list) for this group:
    • Create the file /etc/sudoers.d/operation:

      %operation ALL=(root) NOPASSWD: /usr/bin/cat /etc/shadow

    Please note that authorized commands must be defined with their full path.

    export OPS="$(pwd)" # or relative or absolute path OPSDirectory
    automation-cli run -i "[inventory file]" -h "[ip|host name of remote server]:[SSH port(22)]:[user]" -c "cat /etc/shadow" -sudo"

    The user still doesn’t need a password, but the list of usable commands is now limited. Try replacing cat with ls:

    export OPS="$(pwd)" # or relative or absolute path OPSDirectory
    automation-cli run -i "[inventory file]" -h "[ip|host name of remote server]:[SSH port(22)]:[user]" -c "ls /etc/shadow" -sudo"

    sudo stops to ask for the user’s password, execution is impossible. Try it with SSH, and despite providing the correct password, sudo will refuse to execute this last operation, because this command is not included in the list of commands authorized for this group.

• 3rd step:

  • The “operation” and “operationBook” operations create a bash script, which is sent to the remote server in the /tmp directory. This file is then executed. Using “sudo”, here’s how to set the parameters:
  • Continuing with the previous example, the /etc/sudoers.d/operation file should look like this:

    %operation ALL=(ALL) NOPASSWD: /usr/bin/bash /usr/bin/bash ^/tmp/[0-9]+A$, \
                                   /usr/bin/cat /etc/shadow

    ^/tmp/[0-9]+A$ : This is the signature of a file sent by automation-cli. I’ve left /usr/bin/cat... for the example.

Limiting user action through automation tools can become a real nightmare (sudo documentation)

For hardened systems (OS hardening), execution from “/tmp” is often forbidden (noexec), so an execution implementation for this type of case is under study.