Securing Remote Execution

Remote Execution is a very useful feature of Satellite 6. This long anticipated feature made its first appearance in version 6.2. Much has changed since the days of Remote Command in Satellite 5. Most significantly Remote Execution relies on ssh, instead of a client side daemon. This change introduces some new security considerations for hardened environments. Let's take a closer look.

Security Considerations

This section will outline security requirements from common hardening baselines (CIS, STIG, USGCB, etc.), that affect Remote Execution.

Root Login Disabled

By default Remote Execution attempts to ssh as the root user. This, of course, is not something that is allowed in almost any baseline.  To mitigate this issue, we need to change the remote_execution_ssh_user setting. This can be located by navigating to Administer -> Settings, then clicking the RemoteExecution tab.

Now that this has been configured, we must ensure that this user is available on the systems. This can be a local or LDAP user. We must also setup a sudo rule for this user. This rule should allow the user full access with no password prompt.

In an effort to secure this account, we can disable password authentication for the account. This will ensure that the only way to access this account is via the ssh keys we will be deploying, or by switching to this account from root.

Limit Concurrent SSH Sessions

Many baselines will require the maxsessions option be configured for sshd. If this option is configured, it must be set to a value greater than 1. Remote Execution jobs will fail when MaxSessions is set to 1. This configuration is on the client systems.

Mount /tmp with noexec

Another common requirement is to enable the noexec option on the /tmp mount point. This prevents binary executions in the /tmp directory. This doesn't immediately seem like an issue, but Remote Execution uses /var/tmp as its remote working directory. This poses an issue though because /var/tmp is typically bound to /tmp. This working directory cannot have noexec enabled, so this causes a potential issue.

To mitigate this the option must either be removed, or a different directory must be used. Instructions for changing the working directory can be found here.

New Systems

When provisioning new systems ssh keys for Remote Execution will be automatically deployed, assuming the ssh user is present at the time of build. Sudo rules must still be deployed, and the working directory must be present and correctly configured--if using custom directory.

Migrated Systems

Systems that are migrated to Satellite 6 will require ssh keys to be manually deployed, in addition to the manual steps required for new systems.

Preparing Clients with Puppet

In an effort to try to simplify this process, the `chopskxw-rex` was created. This module will ensure the ssh user is present, deploy a sudoers rule to sudoers.d, deploy ssh keys, and ensure the remote working directory does not have noexec enabled.

This module is available from GitHub or PuppetForge. To configure this module, we will need to set a couple of parameter overrides. You may notice the rex_keys value looks familiar. This has been borrowed from a previous blog post about Remote Execution.

rex_user = <%= @host.params['remote_execution_ssh_user'] %>
rex_keys =
---
ssh_authorized_key:
  <% for _key in @host.params['remote_execution_ssh_keys'] do -%>
  <% key = _key.split(' ') -%>
  <%= key[2] %>:
    user: <%= @host.params['remote_execution_ssh_user'] %>
    type: <%= key[0] %>
    key: <%= key[1] %>
  <% end -%>

Optionally, if using a custom working directory, the rex_dir parameter must be overridden.

rex_dir = '/path/to/dir'

Connect with Red Hat Services

Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn