Backing up SSH Controls configuration files

When making changes to any of the standard SSH Controls configuration files on the SSH master:

  • /etc/ssh_master/access
  • /etc/ssh_master/alias
  • /etc/ssh_master/targets
  • /etc/ssh_master/keys.d/*

Make a backup copy first in the designated directory:

[master]$ /etc/ssh_master/manage_ssh.sh --backup

INFO: *** start of manage_ssh.sh [--backup] ***
INFO: logging takes places in /var/log/manage_ssh.sh.log
INFO: runtime info: LOCAL_DIR is set to: /etc/ssh_master
INFO: ACTION: backing up the current configuration & keys files ...
INFO: resulting backup file is: /etc/ssh_master/backup/backup_repo_20150105-1022.tar.gz
INFO: finished backing up the current configuration & keys files
INFO: performing cleanup ...

Previewing a change in access and alias mappings

Making a change to the SSH Controls configuration can have a large impact in terms of granted access on the client landscape. You can preview the potential effect of your change by requesting a full dump of the configured name space or access rules.

You can do this on the SSH master server or any client with:

[master]$ /etc/ssh_master/manage_ssh.sh --preview-global

The info presented will be 3-element tuples showing: WHO has access WHERE as WHAT:

INFO: display GLOBAL configuration ....
John_Doe|host1|johndoe
John_Doe|host2|johndoe
John_Doe|host3|johndoe
John_Doe|host4|johndoe
John_Doe|host5|johndoe
John_Doe|host6|johndoe
<…>
Jane_Doe|host1|janedoe
Jane_Doe|host2|janedoe
<snip>

By simply ‘grepping’ on the output you can apply filters.

Resolving (expanding) aliases

When using nested groups (aliases) it may be difficult to track what the alias will finally expand to. Use the --resolve-alias command-line option to manually request alias resolution.

Example alias file:

@acme_hosts	: acme1.com,acme2.com,acme3.com,@acme_web
@acme_web	: acme5.come,acme7.com,@acme_db
@acme_db	: acme8.com,acme9.com

You can request manually resolution of @acme_hosts with:

[master]$ /etc/ssh_master/manage_ssh.sh --resolve-alias --alias=@acme_hosts

INFO: ACTION: resolving alias @acme_hosts ...
INFO: alias @acme_hosts resolves to: acme1.com acme2.com acme3.com acme5.come acme7.com acme8.com acme9.com
INFO: finished resolving alias

Or the @acme_db alias:

[master]$ /etc/ssh_master/manage_ssh.sh --resolve-alias --alias=@acme_db

INFO: alias @acme_db resolves to: acme8.com acme9.com
INFO: finished resolving alias
INFO: performing cleanup ...

Manually expanding aliases works on both master and client nodes.

Finding errors in --copy and --update operations

Since SSH Controls will sync & update its clients in parallel via background jobs, it is not easy to always see a potential problem and correlate it to its correct host of origin.

Following command will siphon off the verbose output into a separate log file which can be used for inspection:

[master]$ /etc/ssh_master/manage_ssh.sh --copy 2>&1 | tee /tmp/copy.log

[master]$ /etc/ssh_master/manage_ssh.sh --apply 2>&1 | tee /tmp/apply.log

Then use following pattern to look for problems:

[master]$ grep -i -E -e 'WARN|ERROR|failed|denied|sudo' /tmp/copy.log

[master]$ grep -i -E -e 'WARN|ERROR|failed|denied|sudo' /tmp/apply.log

Fix any potential problems and clean up the temporary log file afterwards:

[master]$ rm –f /tmp/copy.log
[master]$ rm –f /tmp/apply.log

Alternatively you can also check the return code of the different sub-commands. Any return code different from 0 will be indicative of an error or errors:

[master]$ grep -E -e 'RC=[^0]' /tmp/copy.log

WARN: failed to transfer /etc/ssh_master/ssh_master/grants to client1:/etc/ssh_controls/holding [RC=255]
WARN: failed to transfer /etc/ssh_master/ssh_master/grants to client2:/etc/ssh_controls/holding [RC=255]
WARN: failed to transfer ./manage_ssh.sh to client1:/etc/ssh_controls/holding [RC=255]
WARN: failed to transfer ./manage_ssh.sh to client2:/etc/ssh_controls/holding [RC=255]
WARN: failed to transfer ./manage_ssh.conf to client1:/etc/ssh_controls/holding [RC=255]
WARN: failed to transfer ./manage_ssh.conf to client2:/etc/ssh_controls/holding [RC=255]
WARN: failed to transfer /var/tmp/distribute2host.14428/fragments to client1:/etc/ssh_controls/holding [RC=255]
wARN: failed to transfer /var/tmp/distribute2host.2601/fragments to client2:/etc/ssh_controls/holding [RC=255]
WARN: child process 31283 exited [RC=7]
WARN: child process 31223 exited [RC=7]

Following WARning(s) may be ignored:

WARN: no keys blacklist file found
Warning: Permanently added … (RSA) to the list of known hosts

Other messages that may ignored are the ones caused by the sudo tool itself (locally on each client):

Last successful login:       Mon Jan 19 08:50:15 MET 2015   
Last authentication failure: Mon Aug 25 23:18:02 METDST 2014 host1  
Last successful login:       Mon Jan 19 08:50:15 MET 2015   
Last authentication failure: Fri Sep  5 20:25:45 METDST 2014 host2

The following warning message indicates that the xauth utility is not installed on the client host:

X11 forwarding request failed on channel 0

Updated:

Leave a comment