Table of content

www.kudos.be

FAQ

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/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.

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
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.

-OR-

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.

Where do I find log files?

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.

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/manage_ssh.sh --copy && /etc/ssh_master/manage_ssh.sh --update

But: CAVEAT EMPTOR :-)

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 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.

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:

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

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 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.

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

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.




Backlinks: Projects:SSH Controls Projects:SSH Controls:Configuring a client host Projects:SSH Controls:Management scripts Projects:SSH Controls:Troubleshooting tips