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
):access
: see master configuration filesalias
: see master configuration fileskeys.d
orkeys
: see master configuration filestargets
: should contain only the Slave servers or clients that need to updated directly from the Master, see also: see master configuration files
- Slave (
/etc/ssh_controls/holding
):access
: do NOT configure, automatically propagated from the Master serveralias
: do NOT configure, automatically propagated from the Master serverkeys.d
orkeys
: do NOT configure, automatically propagated from the Master servertargets
: 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 serveralias
: do NOT configure, automatically propagated from the Master serverkeys.d
orkeys
: 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:
- Firstly copy from Master → Slave(s) (or Master’s clients)
- 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:
- Using an SSH key with a passphrase: and do either of the following:
- 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.
- 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.
- Using an SSH key without a passphrase: and do either of the following:
- 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.
- 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 2.2 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:
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):
Example of using DO_SSH_AGENT=1
(master→slave→client):
Leave a comment