Table of content

www.kudos.be

Master to slave operations

Introduction

In the traditional, standard fashion SSH Controls is used for propagating data from a master system to directly connected clients via the SSH protocol. Following figure illustrates the model:



The manage_ssh.sh script supports an additional mode of operation: the master -> slave -> client model. This allows SSH Controls to be used with an additional level of connectivity - using SSH also - between master and client systems. Typical examples might be the need to update hosts that are part of segregated LAN segments in which the master server may only contact a subsequent gateway (or slave server) that resides in the segregated LAN. Following figure illustrates the example:


Set-up

The set-up of a Slave server in SSH Controls consists of turning a SSH Controls client repository into a master repository. By "tricking" SSH Controls into thinking the client also serves as a Master, the actual Master server can use this node as a secondary master or Slave server. The fact that this can easily be achieved is mainly thanks to the fact that the entire SSH Controls repository is always available on each client with one notable exception: the targets file. Thus by configuring a local targets file on the Slave server, the Slave server can function as a gateway between the actual Master and the clients defined in the new targets file.

Following list gives a short illustration of the different files that are/should be present on each of the nodes:

  • Master (/etc/ssh_master):
  • Slave (/etc/ssh_controls/holding):
    • access: do NOT configure, automatically propagated from the Master server
    • alias: do NOT configure, automatically propagated from the Master server
    • keys.d or keys: do NOT configure, automatically propagated from the Master server
    • targets: different from the targets file on the Master and should contain the names of the clients to be updated from this Slave server.
  • Client (/etc/ssh_controls/holding):
    • access: do NOT configure, automatically propagated from the Master server
    • alias: do NOT configure, automatically propagated from the Master server
    • keys.d or keys: do NOT configure, automatically propagated from the Master server

Summarizing in terms of configurable items, you should remember:

  • access rules: are ONLY configured on the Master server and should contain information for all clients and Slave servers
  • alias/groups: are ONLY configured on the Master server and should contain information for all clients and Slave servers
  • public keys: are ONLY configured on the Master server and should contain information for all clients and Slave servers
  • targets: should be configured on both Master and Slave server(s). Do not enter clients in more than one targets file.


Basic usage: copy/apply

The manage_ssh.sh script supports an additional command-line parameter --slave to indicate that any copy/apply operation is to be scheduled on the Slave server. By default SSH Controls will only copy/apply its configuration onto the next level, e.g.:

[master]$ manage_ssh.sh --copy : distribute the configuration files TO all hosts that are listed in the targets file on the Master server.

[master]$ manage_ssh.sh --copy --targets=<slave_list> : distribute the configuration files TO all hosts that are mentioned in the --targets list from the Master server.

[master]$ manage_ssh.sh --copy --slave --targets=<slave_list> : distribute the configuration files starting TO all hosts that are mentioned in the --targets list from the Master server ONTO all hosts that are listed in the local targets files on each of the Slave servers.

[master]$ manage_ssh.sh --apply : apply the configuration files TO all hosts that are listed in the targets file on the Master server.

[master]$ manage_ssh.sh --apply --targets=<slave_list> : apply the configuration files TO all hosts that are mentioned in the --targets list from the Master server.

[master]$ manage_ssh.sh --apply --slave --targets=<slave_list> : apply the configuration files TO all hosts that are mentioned in the --targets list from the Master server ONTO all hosts that are listed in the local targets files on each of the Slave servers.

In fact, you will always need to do both operations in sequence in order to update the holding configuration on the Slave servers first:

  1. Firstly copy from Master → Slave(s) (or Master's clients)
  2. Secondly copy/apply from Slave(s) → Clients

The second operation can be triggered from either the Master server (using the --slave command-line option) or from an indivual Slave server, e.g.:

From the Master server:

[master]$ manage_ssh.sh --copy --slave --targets=slave1,slave2,...

From the Slave server:

[slave]$ manage_ssh.sh --copy
[slave]$ manage_ssh.sh --copy --targets=client1,client2,...


Advanced usage: controlling the SSH agent

SSH Controls requires a fully non-interactive SSH connection path from its Master to its client - irrespective of whether a Slave server is used or not - in order to complete its operations. This can only be achieved by using an SSH agent process that can propagate access credentials from one level to the next without manual intervention. There are 2 ways to accomplish this:

  1. Using an SSH key with a passphrase: and do either of the following:
    1. start an SSH agent process on the host from where (e.g. laptop) you connect to the Master server and add an SSH private key to it that will give you the correct access onto all clients.
    2. start the SSH agent process on the Master server itself and add an SSH private key to it that will give you the correct access onto all clients.
  2. Using an SSH key without a passphrase: and do either of the following:
    1. start an SSH agent process on the host from where (e.g. laptop) you connect to the Master server and add an SSH private key to it that will give you the correct access onto all clients.
    2. start the SSH agent process on the Master server itself and add an SSH passphrase-less private key to it that will give you the correct access onto all clients.

When using a Master/Slave server set-up the option is described in 2b is the easiest to manage as SSH Controls supports as it allows the automatic start/stop of the necessary SSH agent. The following configuration options in manage_ssh.conf(.local) controls this behaviour:

# whether to start an SSH agent process for the master->client operations [0=No; 1=Yes]
DO_SSH_AGENT=0

# location of the SSH private key that should be added to the SSH agent process
# must be a passphrase-less key (required when using DO_SSH_AGENT)
SSH_PRIVATE_KEY="$HOME/.ssh/id_rsa"

Make sure the private key in SSH_PRIVATE_KEY is actually present and that it is passphrase-less. Or else the on-demand SSH agent process will fail to function.

Example of using DO_SSH_AGENT=1 (master→client/slave):

[master]$ manage_ssh.sh --copy --targets=client1

INFO: *** start of manage_ssh.sh [--copy --targets=client1] /18268@master/ ***
INFO: logging takes places in /var/log/manage_ssh.sh.log
INFO: runtime info: LOCAL_DIR is set to: /etc/ssh_master
INFO: ACTION: copy/distribute SSH controls
INFO: requested to start an SSH agent on master ...
INFO: SSH agent started on master:
INFO: UID        PID  PPID  C STIME TTY          TIME CMD
INFO: sshadmin 18294     1  0 18:30 ?        00:00:00 ssh-agent
INFO: adding private key /etc/ssh_master/.ssh/id_rsa to SSH agent on master ...
INFO: Identity added: /etc/ssh_master/.ssh/id_rsa (/etc/ssh_master/.ssh/id_rsa)
INFO: copying/distributing to client1 in background [PID=18311] ...
INFO: transferred /etc/ssh_master/access to client1:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_master/alias to client1:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_master/update_ssh.pl to client1:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_master/update_ssh.conf to client1:/etc/ssh_controls/holding
INFO: transferred ./manage_ssh.sh to client1:/etc/ssh_controls/holding
INFO: transferred ./manage_ssh.conf to client1:/etc/ssh_controls/holding
INFO: keys are stored in a DIRECTORY, first merging all keys into /var/tmp/distribute2host.22969/keys
INFO: transferred /var/tmp/distribute2host.22969/keys to client1:/etc/ssh_controls/holding
INFO: child process 18311 exited [RC=0]
INFO: stopping SSH agent (if needed) on master ...
INFO: stopping (TERM) process on master with PID: 18294
INFO: UID        PID  PPID  C STIME TTY          TIME CMD
INFO: sshadmin 18294     1  2 18:30 ?        00:00:00 ssh-agent
INFO: finished copying/distributing SSH controls
INFO: performing cleanup ...
INFO: *** finish of manage_ssh.sh [--copy --targets=client1] /18268@master/ ***

Example of using DO_SSH_AGENT=1 (master→slave→client):

[master]$ manage_ssh.sh --copy --slave --targets=slave1

INFO: *** start of manage_ssh.sh [--copy --slave --targets=slave1] /18650@master/ ***
INFO: logging takes places in /var/log/manage_ssh.sh.log
INFO: runtime info: LOCAL_DIR is set to: /etc/ssh_master
INFO: ACTION: copy/distribute SSH controls
INFO: requested to start an SSH agent on master ...
INFO: SSH agent started on master:
INFO: UID        PID  PPID  C STIME TTY          TIME CMD
INFO: sshadmin 18677     1  0 18:34 ?        00:00:00 ssh-agent
INFO: adding private key /etc/ssh_master/.ssh/id_rsa to SSH agent on master ...
INFO: Identity added: /etc/ssh_master/.ssh/id_rsa (/etc/ssh_master/.ssh/id_rsa)
INFO: copying/distributing to slave1 in background [PID=18694] ...
INFO: copying SSH controls on slave1 in slave mode, this may take a while ...
INFO: *** start of manage_ssh.sh [--copy] /27658@pi1/ ***
INFO: logging takes places in /var/log/manage_ssh.sh.log
INFO: runtime info: LOCAL_DIR is set to: /etc/ssh_controls/holding
INFO: ACTION: copy/distribute SSH controls
INFO: copying/distributing to client1 in background [PID=27679] ...
INFO: copying/distributing to watt in background [PID=27685] ...
INFO: transferred /etc/ssh_controls/holding/access to client1:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_controls/holding/access to watt:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_controls/holding/alias to client1:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_controls/holding/update_ssh.pl to client1:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_controls/holding/alias to watt:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_controls/holding/update_ssh.conf to client1:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_controls/holding/update_ssh.pl to watt:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_controls/holding/manage_ssh.sh to client1:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_controls/holding/manage_ssh.conf to client1:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_controls/holding/update_ssh.conf to watt:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_controls/holding/keys to client1:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_controls/holding/manage_ssh.sh to watt:/etc/ssh_controls/holding
INFO: child process 27679 exited [RC=0]
INFO: transferred /etc/ssh_controls/holding/manage_ssh.conf to watt:/etc/ssh_controls/holding
INFO: transferred /etc/ssh_controls/holding/keys to watt:/etc/ssh_controls/holding
INFO: child process 27685 exited [RC=0]
INFO: finished copying/distributing SSH controls
INFO: performing cleanup ...
INFO: *** finish of manage_ssh.sh [--copy] /27658@pi1/ ***
INFO: child process 18694 exited [RC=0]
INFO: stopping SSH agent (if needed) on master ...
INFO: stopping (TERM) process on master with PID: 18677
INFO: UID        PID  PPID  C STIME TTY          TIME CMD
INFO: sshadmin 18677     1  2 18:34 ?        00:00:00 ssh-agent
INFO: finished copying/distributing SSH controls
INFO: performing cleanup ...
INFO: *** finish of manage_ssh.sh [--copy --slave --targets=slave1] /18650@master/ ***



Backlinks: Projects:SSH Controls Journal:2015:Oct-03 - SSH+SUDO Controls updates Projects:SSH Controls:Requirements & components