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:
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/manage_ssh.sh --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.
SSH public keys may come in either of following formats:
Type 1 (openSSH format):
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqfLOWzsG06vlDEJZldHLUuDZm/gr0Sz+Nr6L7yT1FLCcXm9rLCQgfdCl uVxPmxWCFa7SJRwl1mX/rm1Cj5UxPHM+7vaeov3TxidJGd6vGlHlVW3U+YWR4wbkzIaSzipilsJJgazGgmeau4dY81sj FO0MzEe8r4XRXm1de30+4oD0Iy5mXGVtyXWCeUZ/SXa7NwXlSLiOaxiWf9e5ujjEldwPz4H4ad5y3U4QCqSySRVg51Yv 34vNgfCP0BhtEU2uq6PPB1CbW3b3Js89AQIg45c1DZ3RUUTTzLoSXIEp1Aj7pAZd9eJ0kjwhNytmUANG8fOkbqtpGZLf 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):
---- BEGIN SSH2 PUBLIC KEY ---- Comment: "John Doe" AAAAB3NzaC1yc2EAAAABJQAAAQEAxv1h446sRz/U/vYmP57M+E81dUYGYmvrRATk dSPbzQbdnAfqRU7cX/hhi9wBtD/Y/c3qSFKMQHZC09PnDJ6/5u6e66KjpWAHyvhs 4AH8IzQIavap7p8NA9Sr57DrKS0I0YNJZq2kkeAxDD8ZJCZOj6ssMpjGbSZeocMx iciuFJShyoxlugecsi3MXgin60VLC+vWj/uOiEuRx2OqpJa/OavrvMSU4am4Vn36 jKyQqyNARGeTjbvgG+OvgccvvBFgId3MgxeKhBQ1hxoW7McWVqkzyX/Vqlg1jw04 aMeDSouT5TOBisQrd8cpMWKg6/vqTW/B6bCs0dfnj2lnDgUS7Q== ---- END SSH2 PUBLIC KEY ----
For SSH Controls you must convert keys into the OpenSSH format first.
The manage_ssh.sh 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 update_ssh.pl script does not perform any logging but will do so when called through the manage_ssh.sh script.
SSH Controls will re-label the public keys files under /etc/ssh_controls/keys.d as follows upon each update:
This will make sure that sshd can access the required keys at all times.
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/manage_ssh.sh --copy && /etc/ssh_master/manage_ssh.sh --update
But: CAVEAT EMPTOR :-)
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:
Dec 22 15:33:24 s51lv34 sshd: 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: Accepted publickey for johndoe from 10.10.10.1 port 61870 ssh2
This means that we can potentially tell WHEN someone accessed a system but not what you did after the logon.
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:
Jane_Doe,ssh-rsa,AAAAB3NzaC1yc2EAAAABIwAAAQEAqd2Tg3Nql5K0Ed9YxKlOa6ObxJn8BOK8b4K3JPGc67NWm7A8soMPFAk SHvl2lWt856JCvaYaxblvS79I8n8wnf5EXr++Rbh3rId9UAj2ZyJp+DTn5Ryoxo2XExeRZiqp8LH7Ob2pspZ5gdbTrxBFgSFMYo0 9SC1qdVXSo+R2wQgfhvk81Z2TB4AHZY033lpUAOiQ8ZxKfH6k/Jsz2UVTI5oZ9CzetiSiHgNdYL+0uzMADn3nMAdkj0YWJqkuGbE vNVZkEV0BKKjuyDUBRrdZ1C6ZJ6fuB5m4jf2v0Ym1NJRb5uT4IcGv3rIx14YtjEdqCjNlnoqCYPsDFD+gELS2hQ==
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 .... <snip>
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
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.
These are configuration files that can be used to define settings for the manage_ssh.sh 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.
These are configuration files that can be used to define settings for the update_ssh.pl 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.