Can SSH Controls update public keys in the standard $HOME/.ssh locations?

Yes. You may choose to have your public keys copied into a central, common location - as recommended by SSH Controls and documented here - or to a location that is specified by the AuthorizedKeysFile parameter in the sshd_config file. However, you must choose between of one of these two models (do not mix them as you will likely end up with unmanaged public keys in different locations).

In order to switch the standard $HOME/.ssh location: set key_location=use_sshd in update_ssh.conf[.local] and leave AuthorizedKeysFile in** sshd_config** to its preconfigured default setting of .ssh/authorized_keys

Note that it is possible to use a different scheme for different hosts, for example to use a common location for all hosts except a few:

  • configure key_location=use_controls in update_ssh.conf for all your client hosts
  • configure key_location=use_sshd in update_ssh.conf.local for all hosts that are to be an exception to the above rule.

Why are file permissions (DAC) important in SSH Controls?

Well that depends on whether if you are administrating SSH Controls using the sshadmin account only or using multiple accounts. In the former case the following DAC considerations do not apply. However you may want to opt to administrator SSH Controls with multiple people each having their own account. This is possible on the condition that these accounts are part of the sshadmin group on both SSH master & client hosts. In this case, the following DAC considerations do apply:

  • SSH Controls files should be group owned AND group writeable by sshadmin so that only members of this group can manipulate them. The actual authorized keys files in /etc/ssh_controls/keys.d/* should always be world-readable though.
  • When syncing files remotely, the files in the target repository need to be writeable by everybody in the group sshadmin.

When in doubt about permissions of the files in the local SSH Controls repositories (not the SSH master), you can use the --fix-local command to reset permissions:

[client]$ /etc/ssh_controls/ --fix-local --fix-dir=/etc/ssh_controls [--fix-user=sshadmin]

There is a corresponding --fix-remote command as well that can be executed on the SSH master.

Why are not all SSH public key files similar?

SSH public keys may come in either of following formats:

Type 1 (openSSH format):

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqfLOWzsG06vlDEJZldHLUuDZm/gr0Sz+Nr6L7yT1FLCcXm9rLCQgfdCl
RMtMi7FxGQ== johndoe@host1

The key content should be all on ONE line but is split into multiple lines here to increase readability.


Type 2 (RFC 4716 format):

Comment: "John Doe"

For SSH Controls you must convert keys into the OpenSSH format first.

Where do I find log files?

The script writes its actions – unless you specify the --no-log parameter – into the /var/log directory. This is valid for both SSH master and clients.

The script does not perform any logging but will do so when called through the script.

How does SSH Controls deal with SELinux (MAC)?

SSH Controls will re-label the public keys files under /etc/ssh_controls/keys.d as follows upon each update:

  • RHEL 5 (or derivatives):
# chcon -R -t sshd_key_t /etc/ssh_controls/keys.d/*`
  • RHEL 6/7 (or derivatives):
# chcon -R -t ssh_home_t /etc/ssh_controls/keys.d/*`

This will make sure that sshd can access the required keys at all times.

Can I run –copy and –update in one go?

Nope. You should always make sure that files are correctly transferred before applying them.

But of course, nothing prevents you from running:

[master]$ /etc/ssh_master/ --copy && /etc/ssh_master/ --update


How does SSH fingerprinting work?

Wikipedia says:

In public-key cryptography, a public key fingerprint is a short sequence of bytes used to authenticate or look up a longer public key. Fingerprints are created by applying a cryptographic to a public key. Since fingerprints are shorter than the keys they refer to, they can be used to simplify certain key management tasks.

In short: we can use fingerprints to identify keys (and their owners). For that purposes, fingerprints are logged upon accessing a system:

Linux @/var/log/secure:

Dec 22 15:33:24 s51lv34 sshd[30070]: Found matching RSA key: ff:ee:ff:46:2c:56:e7:83:d5:3f:78:61:51:0f:ba:d1
Dec 22 15:33:24 s51lv34 sshd[30070]: Accepted publickey for johndoe from port 61870 ssh2

This means that we can potentially tell WHEN someone accessed a system but not what you did after the logon.

How can I blacklist a public key?

A SSH public key may be ‘blacklisted’ (i.e. rejected when applying/update SSH Controls) by adding an entire key definition into the file defined in the blacklist_file setting in update_ssh.conf(.local).

For example: the following entry in the keys file needs to be blacklisted:


When added to a blacklist file, any SSH Controls update will yield:

INFO: runtime info: root; host1@.; Perl v5.008008
INFO: parsing configuration file(s) ...
INFO: checking for SSH control mode ...
INFO: host is under SSH control via /etc/ssh_controls/keys.d
INFO: checking for keys blacklist file ...
INFO: keys blacklist file found with 1 entr(y|ies)
INFO: reading user accounts from /etc/passwd ...
INFO: 34 user accounts found
INFO: reading 'alias' file ...
INFO: 70 aliases found
INFO: reading 'keys' file(s) ...
INFO: local 'keys' are stored in a FILE
INFO: reading public keys from file: ./keys
WARN: *BLACKLIST*: key match found for Jane_Doe,ssh-rsa,AAAAB3NzaC1yc2EA...', ignoring key!
INFO: 288 public key(s) found
INFO: reading 'access' file ...
INFO: 15 accounts with applicable access rules found
INFO: applying SSH access rules ....

Blacklisting can be used to keep track of compromised keys or keys that may not be re-used. It does mean however that they must also remain within the SSH Controls master repository as configured public key (tip: isolate them into a separate key group file, e.g.: /etc/ssh_master/keys.d/bad.keys

What is the difference between the keys.d directory on the SSH master and the keys.d directory on any SSH Controls managed client?

On the SSH master /etc/ssh_master/keys.d directory represents the central repository of all available public keys. These keys may be stored in key group files, organized per department, application or team etc. These keys do NOT provide any access to the SSH master and can only be manipulated by the SSH Controls maintainers.

The client’s /etc/ssh_controls/keys.d directory represents the managed location of the authorized_keys files – organized per account – which will be read by sshd to provide access to the client system. These files should never be manipulated manually.

The SSH master should have a master and client repository when it also being managed by its own SSH Controls framework.

What are the manage_ssh.conf & manage_ssh.conf.local files?

These are configuration files that can be used to define settings for the script. The manage_ssh.conf can be used as a global configuration file whereas manage_ssh.conf.local can serve as a local override. The former will also be distributed by SSH Controls, the latter not.

What are the update_ssh.conf & update_ssh.conf.local files?

These are configuration files that can be used to define settings for the script. The update_ssh.conf can be used as a global configuration file whereas update_ssh.conf.local can serve as a local override. The former will also be distributed by SSH Controls, the latter not.