Push via Salt SSH

Push via Salt SSH is used in environments where Salt clients cannot reach the Uyuni Server directly. In this environment, clients are located in a firewall-protected zone called a DMZ. No system within the DMZ is authorized to open a connection to the internal network, including the Uyuni Server.

The Push via Salt SSH method creates an encrypted tunnel from the Uyuni Server on the internal network to the clients located on the DMZ. After all actions and events are executed, the tunnel is closed.

The server uses the salt-ssh tool to contact the clients at regular intervals, checking in and performing scheduled actions and events. For more information about Salt SSH, see Salt SSH.

This contact method works for Salt clients only. For traditional clients, use Push via SSH.

This image demonstrates the Push via Salt SSH process path. All items left of the Taskomatic block represent processes running on a Uyuni client.

salt ssh contact taigon

To use Push via Salt SSH, you must have the SSH daemon running on the client, and reachable by the salt-api daemon running on the Uyuni Server. Additionally, Python must be available on the remote system, and be a version supported by Salt.

Red Hat Enterprise Linux 5, CentOS 5, and earlier are not supported, as they use unsupported versions of Python.

Procedure: Registering Clients with Push via Salt SSH
  1. In the Uyuni Web UI, navigate to Systems  Bootstrapping and complete the appropriate fields.

  2. Select an activation key with the Push via SSH contact method configured. For more information about activation keys, see Activation Keys.

  3. Check the Manage system completely via SSH checkbox.

  4. Click Bootstrap to begin registration.

  5. Confirm that the system has been registered correctly by navigating to Systems  Overview.

Available Parameters

When you are configuring Push via Salt SSH, you can modify parameters that are used when a system is registered, including the host, activation key, and password. The password is used only for bootstrapping, it is not saved anywhere. All future SSH sessions are authorized via a key/certificate pair. These parameters are configured in Systems  Bootstrapping.

You can also configure persistent parameters that are are used system-wide, including the sudo user. For more information on configuring the sudo user, see Push via SSH.

Action Execution

The Push via Salt SSH feature uses taskomatic to execute scheduled actions using salt-ssh. The taskomatic job periodically checks for scheduled actions and executes them. Unlike Push via SSH on traditional clients, the Push via Salt SSH feature executes a complete salt-ssh call based on the scheduled action.

By default, actions are executed sequentially on each client, and only one action will run at a time. You can increase the number of actions that can be executed in parallel, by adding this line to your configuration file, and adjusting the number upwards. We recommend you keep the number of parallel actions low, to avoid problems:


This will adjust the number of actions that can run in parallel on any one client. If actions needs to be run on multiple clients, actions will always be executed sequentially on each client.

If the clients are connected through a Uyuni Proxy, you will need to adjust the MaxSessions settings on the proxy. In this case, set the number of parallel connections to be three times the total number of clients.

Future Features

There are some features that are not yet supported on Push via Salt SSH. These features will not work on Salt SSH clients:

  • OpenSCAP auditing

  • Beacons, resulting in:

    • Installing a package on a system using zypper will not invoke the package refresh.

    • Virtual Host functions (for example, a host to guests) will not work if the virtual host system is Salt SSH-based.

For more information about Salt SSH, see https://docs.saltstack.com/en/latest/topics/ssh/.