SSH Push (With Tunnel) Contact Method

SSH Push (with tunnel) (ssh-push-tunnel) is used in environments where 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.

In other words: SSH Push (with tunnel) also creates a reverse tunnel from the client to the Uyuni Server, not only from the server to the client.

The server uses SSH to contact the clients at regular intervals, checking in and performing scheduled actions and events.

Re-installing systems using the provisioning model is not currently supported on clients managed with SSH Push.

The tunnel is used to provide the access to the server through the encrypted tunnel. The repositories assigned to the SSH Push client (with tunnel) are provided through this tunnel only, thus it is not possible to use package manager tools directly from the client system because the repositories are available only while the tunnel is up. In other words, access is only possible if the session is initiated by the server. All package managing operations on the client can be performed from the server side only.

Use mgrctl term before running steps inside the server container.

For tunneling connections via SSH, a port number is required for tunneling via HTTPS. The port number used by default is 1233. To overwrite it, inside the container, you can add a custom port numbers greater than 1024 to /etc/rhn/rhn.conf:

ssh_push_port_https = high_port

After changing this configuration parameter you must restart services such as salt-secrets-config.service, tomcat.service, and taskomatic.service. To cover all needed services, it is the best to restart the Uyuni Server as root. Outside of the container, from the container host, enter:

mgradm restart

For security reasons, you might want to use sudo with SSH, to access the system as an unprivileged user instead of as root.

Procedure: Configuring Unprivileged SSH Access
  1. On each client system, create an appropriate unprivileged user.

  2. On each client system, edit the sudoers file:

    sudo visudo
  3. Grant sudo access to the user by adding this line at the end of the sudoers file. Replace <user> with the name of the user that is bootstrapping the client in the Web UI:

    <user>  ALL=NOPASSWD: /usr/bin/python3, /var/tmp/venv-salt-minion/bin/python

    This procedure grants root access without requiring a password, which is required for registering the client. When the client is successfully installed it runs with root privileges, so the access is no longer required. We recommend that you remove the line from the sudoers file after the client has been successfully installed.

  4. Inside the Uyuni Server container, edit the /etc/rhn/rhn.conf configuration file, and add or amend this line to include the unprivileged username:

    ssh_push_sudo_user = <user>

After changing this configuration parameter you must restart services such as salt-secrets-config.service, tomcat.service, and taskomatic.service. To cover all needed services, it is the best to restart the Uyuni Server as root. Outside of the container, from the container host, enter:

mgradm restart

You need to use the Web UI or API to register these clients with the Uyuni Server.

Before you begin, you need to ensure that you have specified which ports to use for SSH tunneling. If you have registered clients before changing the port numbers, they need to be registered again with a re-activation key.

Example: API Access to SSH Push (with tunnel)

You can use the API to manage which contact method to use. This example Python code sets the contact method to ssh-push-tunnel.

client = xmlrpclib.Server(SUMA_HOST + "/rpc/api", verbose=0)
key = client.auth.login(SUMA_LOGIN, SUMA_PASSWORD)
client.system.setDetails(key, 1000012345, {'contact_method' : 'ssh-push-tunnel'})

Valid values are:

  • default (pull)

  • ssh-push

  • ssh-push-tunnel