13.2.9. Configuring Services: OpenSSH and Cached Keys
OpenSSH creates secure, encrypted connections between two systems. One machine authenticates to another machine to allow access; the authentication can be of the machine itself for server connections or of a user on that machine. OpenSSH is described in more detail in Chapter 14, OpenSSH.
This authentication is performed through public-private key pairs that identify the authenticating user or machine. The remote machine or user attempting to access the machine presents a key pair. The local machine then elects whether to trust that remote entity; if it is trusted, the public key for that remote machine is stored in the
known_hostsfile or for the remote user in
authorized_keys. Whenever that remote machine or user attempts to authenticate again, the local system checks the
authorized_keysfile first to see if that remote entity is recognized and trusted. If it is, then access is granted.
The first problem comes in verifying those identities reliably.
known_hostsfile is a triplet of the machine name, its IP address, and its public key:
server.example.com,255.255.255.255 ssh-rsa AbcdEfg1234ZYX098776/AbcdEfg1234ZYX098776/AbcdEfg1234ZYX098776=
known_hostsfile can quickly become outdated for a number of different reasons: systems using DHCP cycle through IP addresses, new keys can be re-issued periodically, or virtual machines or services can be brought online and removed. This changes the host name, IP address, and key triplet.
Administrators have to clean and maintain a current
known_hostsfile to maintain security. (Or system users get in the habit of accepting any machine and key presented, which negates the security benefits of key-based security.)
Additionally, a problem for both machines and users is distributing keys in a scalable way. Machines can send their keys as part of establishing an encrypted session, but users have to supply their keys in advance. Simply propagating and then updating keys consistently is a difficult administrative task.
Lastly, SSH key and machine information are only maintained locally. There may be machines or users on the network which are recognized and trusted by some systems and not by others because the
known_hostsfile has not been updated uniformly.
The goal of SSSD is to server as a credentials cache. This includes working as a credentials cache for SSH public keys for machines and users. OpenSSH is configured to reference SSSD to check for cached keys; SSSD uses Red Hat Linux's Identity Management (IPA) domain as an identity, and Identity Management actually stores the public keys and host information.
Only Linux machines enrolled, or joined, in the Identity Management domain can use SSSD as a key cache for OpenSSH. Other Unix machines and Windows machines must use the regular authentication mechanisms with the
Configuring OpenSSH to Use SSSD for Host Keys
OpenSSH is configured in either a user-specific configuration file (
~/.ssh/config) or a system-wide configuration file (
/etc/ssh/ssh_config). The user file has precedence over the system settings and the first obtained value for a parameter is used. The formatting and conventions for this file are covered in Chapter 14, OpenSSH.
In order to manage host keys, SSSD has a tool,
sss_ssh_knownhostsproxy, which performs two operations:
- Asks SSSD to retrieve the public host key from the Identity Management server and store it in the
- Establishes a connection with the host machine, using either a socket (the default) or a proxy command.
This tool has the format:
sss_ssh_knownhostsproxy [-d sssd_domain] [-p ssh_port] HOST [PROXY_COMMAND]
Table 13.4. sss_ssh_knownhostsproxy Options
|Short Argument||Long Argument||Description|
|HOSTNAME|| Gives the host name of the host to check and connect to. In the OpenSSH configuration file, this can be a token, |
|PROXY_COMMAND|| Passes a proxy command to use to connect to the SSH client. This is similar to running |
|-d sssd_domain||--domain sssd_domain||Only searches for public keys in entries in the specified domain. If not given, SSSD searches for keys in all configured domains.|
|-p port||--port port||Uses this port to connect to the SSH client. By default, this is port 22.|
To use this SSSD tool, add or edit two parameters to the
- Specify the command to use to connect to the SSH client (
ProxyCommand). This is the
sss_ssh_knownhostsproxy, with the desired arguments and host name.
- Specify the location of the SSSD hosts file (
For example, this looks for public keys in all configured SSSD domains and connects over whatever port and host are supplied:
ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h GlobalKnownHostsFile /var/lib/sss/pubconf/known_hosts
Configuring OpenSSH to Use SSSD for User Keys
SSSD can provide user public keys to OpenSSH. The keys are read by the SSH daemon,
sshd, directly from the output of the
sss_ssh_authorizedkeystool and are not stored in a file.
sshdto read a user's public keys from an external program, in this case the
sss_ssh_authorizedkeystool, use the AuthorizedKeysCommand directive in the
sss_ssh_authorizedkeystool can be used to acquire SSH public keys from the user entries in the Identity Management (IPA) domain and output them in OpenSSH
authorized_keysformat. The command has the following format:
sss_ssh_authorizedkeys [-d sssd_domain] USER
Table 13.5. sss_ssh_authorizedkeys Options
|Short Argument||Long Argument||Description|
|USER|| The user name or account name for which to obtain the public key. In the OpenSSH configuration file, this can be represented by a token, |
|-d sssd_domain||--domain sssd_domain||Only search for public keys in entries in the specified domain. If not given, SSSD searches for keys in all configured domains.|
This feature is configured in
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandRunAs nobodyThese and further options are documented in the
sshd_config(5)man page. Note that the
sshdservice must be restarted for any changes to take effect.