SUSE Manager/SSHServerPush

From MicroFocusInternationalWiki
Revision as of 13:43, 29 November 2016 by Keichwa (Talk | contribs) (feature is called Push via SSH; cleanup)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

SUSE Manager Main Page

Note: This page is related to the Push via SSH feature used with the traditional systems. For the Push via Salt SSH method, see SUSE Manager/SaltSSHServerPush.

Push via SSH

This feature was originally intended to be used for managing clients that due to the technical environment cannot reach the SUSE Manager server to regularly check in to fetch package updates etc. Therefore the server itself will contact the clients in regular intervals using the SSH protocol in order to perform all actions via an encrypted channel.

Server Configuration

For tunneling connections via SSH, two available high port numbers (> 1024) are needed: one is for tunneling HTTP and one for HTTPS (where HTTP is only needed during the registration process). Port numbers used by default are 1232 and 1233. In order to overwrite these, add your preferred values in /etc/rhn/rhn.conf:

 ssh_push_port_http = <high port 1>
 ssh_push_port_https = <high port 2>

These ports must be specified before the first client is registered! Clients registered before changing the port numbers will need to be registered again, otherwise the server will not be able to contact them anymore.

In case the clients should be contacted via their hostnames instead of their IP addresses, there is the following option that can be enabled in rhn.conf as well:

 ssh_push_use_hostname = true

It is further possible to adjust the number of threads to use for opening SSH connections to clients in parallel (by default only two parallel threads are used):

 taskomatic.ssh_push_workers = <number>


If you wish to use sudo and a user different than root, you can set the following in rhn.conf (requires: spacewalk-taskomatic >= and spacewalk-certs-tools =>

 ssh_push_sudo_user = <user>

With this option set it will use sudo with the supplied user. This user has to be created on the client and the following should be set in sudo: Disable the following:

 #Defaults targetpw   # ask for the password of the target user i.e. root
 #ALL    ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults targetpw'!

Add the following:

 <user> ALL=(ALL) NOPASSWD:/usr/sbin/rhn_check
 <user> ALL=(ALL) NOPASSWD:/home/<user>/
 <user> ALL=(ALL) NOPASSWD:/home/<user>/

Also for the user the following should be added in the /home/<user>/.bashrc:

 export PATH

Client Registration

Registration of a client that itself is not able to reach the server obviously needs to be done from within the server. Therefore we are shipping a tool called mgr-ssh-push-init. This command expects a client's hostname (or IP address) as well as the path to a valid bootstrap script in the server's filesystem for registration as parameters:

 $> mgr-ssh-push-init --client <client> --register <bootstrap_script> --tunnel

For registration of systems that should be managed via the SSH push contact method, it is advised to use an activation key that is configured to enable that contact method. Find the UI for creating and modifying activation keys here:

 Systems -> Activation Keys -> Edit key or create new one -> Modify "Contact Method" -> Click "Update Activation Key"

All systems registered with an activation key will be pre-configured to be contacted by the server using the method specified in the key. Currently available server contact methods are:

  • Pull via XMLRPC: the longtime default: clients contact the server themselves
  • Push via SSH: server will contact the client using SSH and run rhn_check there
  • Push via SSH tunnel: server will contact the client and run rhn_check via an encrypted SSH tunnel

The registraton tool will once ask for the client's root password, which is necessary for pushing the SSH public key to the client. Once the key is installed onto the client machine, the SUSE Manager server can log in to the client using key authentication for establishing the SSH tunnel needed for the server-initiated communications. For already registered systems it is still possible to change the contact method in the system details UI:

 Systems -> Select system -> Follow link "Edit These Properties" -> Modify "Contact Method" -> Click "Update Properties"

In order to enable a client to be managed using Push via SSH (without tunneling), the same script can be used as with tunneling. Registration is optional since it can also be done from within the client in this case. Note that mgr-ssh-push-init will also automatically generate the necessary SSH key pair if it does not yet exist on the server:

 $> mgr-ssh-push-init --client <client> [--register <bootstrap_script>]

When using the Push via SSH tunnel contact method, please note that the client is configured to connect SUSE Manager via <high port[1|2]> (see /etc/sysconfig/rhn/up2date). In other words, tools like rhn_check and zypper will need an active SSH session with the proper port forwarding options in order to access the SUSE Manager API. To verify the Push via SSH tunnel connection manually, you can run e.g. this on the SUSE Manager server:

 $> ssh -i /root/.ssh/id_susemanager -R <high port2>:<susemanager>:443 <client> zypper ref

API Support

The contact method to be used for managing a server can also be modified via the API. The following example code (python) shows how to set a system's contact method to 'ssh-push' (valid values are: 'default' (pull), 'ssh-push' and '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'})

Note that whenever a system should be migrated to be managed using SSH push, it needs to be setup with the mgr-ssh-push-init script before the server can actually connect via SSH. This is a separate command since it requires human interaction in order to install the server's SSH key onto the managed client (root password). The procedure to migrate an already registered system to be managed via SSH push is therefore as follows:

  1. Setup the client using the mgr-ssh-push-init script (without --register)
  2. Change the client's contact method to 'ssh-push' or 'ssh-push-tunnel' respectively (via API or web UI)

Existing activation keys can also be edited via API to use the SSH push contact method for clients registered with these keys:

 client.activationkey.setDetails(key, '1-mykey', {'contact_method' : 'ssh-push'})

Proxy Support

It is possible to use the SSH push contact methods to manage systems that are connected to the SUSE Manager server via a proxy. For the registration of such a system, please run mgr-ssh-push-init from within the proxy system that is next to the respective client. Therefore please update the proxy to the latest beta packages to make the registration tool available.

Since the server needs to ssh into the proxy and issue another ssh command to be executed on the client, it is necessary to copy the ssh key to the proxy. This can be achieved by simply issuing the command on the server:

 $> mgr-ssh-push-init --client <proxy>

This will even work with a chain of cascading SUSE Manager proxies, while the only known limitation is that the server needs to be able to directly connect to the last proxy in the chain.

Known Issues

Checkbox not marked after registration

In this early stage of the SSH server push feature, the checkbox to activate a system for server push is not automatically checked after registration via mgr-ssh-push-init. This will be added in a later version.

Systems not checking in

Clients managed via SSH push will obviously appear as not checking in with SUSE Manager after a certain period of time. This is the case because they are actually not running rhn_check regularly themselves.

Client hostname unknown

When registering a SLES 11 SP1 client via the SSH push feature, there is still a bug in the client tools leading to the client's hostname showing up as 'unknown' in the web UI. We fixed this bug for SLES 10 as well as SLES 11 SP2, please update client packages.

Certain actions not supported

Certain actions may currently be not supported to be scheduled for clients that are managed via SSH push. This includes the re-installation of a system using the provisioning module. Further, image deployments using SUSE Studio will work only if the vhost is allowed to directly connect to the SUSE Studio image store for being able to download images.