Product SiteDocumentation Site

⁠7.2.8. Configuring OpenSSH to Check SSSD for Cached Keys (TECH PREVIEW)

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 8, 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_hosts file or for the remote user in authorized_keys. Whenever that remote machine or user attempts to authenticate again, the local system simply checks the known_hosts or authorized_keys file 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.
The known_hosts file 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=
The known_hosts file 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 hostname, IP address, and key triplet.
Administrators have to clean and maintain a current known_hosts file to maintain security. (Or system users get in the habit of simply accepting any machine and key presented, which negates the security benefits of key-based security.)
Additionally, problem for both machines and users is distributing keys in a scalable way. Machines can send their keys are 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_hosts file 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 IPA actually stores the public keys and host information.

NOTE

Only Linux machines enrolled, or joined, in the IPA domain can use SSSD as a key cache for OpenSSH. Other Unix machines and Windows machines must use the regular authentication mechanisms with the known_hosts file.

⁠7.2.8.1. 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 paramter is used. The formatting and conventions for this file are covered in Chapter 8, OpenSSH.
In order to manage host keys, SSSD has a tool, sss_ssh_knownhostsproxy, which performs three operations:
  1. Retrieves the public host key from the enrolled Linux system.
  2. Stores the host key in a custom hosts file, .ssh/sss_known_hosts.
  3. Establishes a connection with the host machine, either a socket (the default) or a secure connection.
This tool has the format: 
sss_ssh_knownhostsproxy [-d sssd_domain] [-p ssh_port] HOST [PROXY_COMMAND]
⁠

Table 7.9. sss_ssh_knownhostsproxy Options

Short Argument Long Argument Description
HOSTNAME Gives the hostname of the host to check and connect to. In the OpenSSH configuration file, this can be a token, %h.
PROXY_COMMAND Passes a proxy command to use to connect to the SSH client. This is similar to running ssh -o ProxyCommand=value. This option is used when running sss_ssh_knownhostsproxy from the command line or through another script, but is not necessary in the OpenSSH configuration file.
-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 ssh_config or ~/.ssh/config file:
  • Specify the command to use to connect to the SSH client (ProxyCommand). This is the sss_ssh_knownhostsproxy, with the desired arguments and hostname.
  • Specify the location of the SSSD hosts file, rather than the default known_hosts file (UserKnownHostsFile). The SSSD hosts file is .ssh/sss_known_hosts.
For example, this looks for public keys in the IPA1 SSSD domain and connects over whatever port and host are supplied: 
ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p -d IPA1 %h
UserKnownHostsFile2 .ssh/sss_known_hosts

⁠7.2.8.2. Configuring OpenSSH to Use SSSD for User Keys

User keys are stored on a local system in the authorized_keys file for OpenSSH. As with hosts, SSSD can maintain and automatically update a separate cache of user public keys for OpenSSH to refer to. This is kept in the .ssh/sss_authorized_keys file.
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 paramter is used. The formatting and conventions for this file are covered in Chapter 8, OpenSSH.
In order to manage user keys, SSSD has a tool, sss_ssh_authorizedkeys, which performs two operations:
  1. Retrieves the user's public key from the user entries in the Identity Management (IPA) domain.
  2. Stores the user key in a custom file, .ssh/sss_authorized_keys, in the standard authorized keys format.
This tool has the format: 
sss_ssh_authorizedkeys [-d sssd_domain] USER
⁠

Table 7.10. sss_ssh_authorizedkeys Options

Short Argument Long Argument Description
USER Gives the username or account name for which to obtain the public key. In the OpenSSH configuration file, this can be represented by a token, %u.
-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.
There are two possible options for how to configure OpenSSH to use SSSD for user keys, depending on the SSH deployment:
  • Most commonly, SSH supports the authorized key command. In that case, it is necessary only to specify the command to run to retrieve user keys. For example: 
    AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
  • SSH can also support a public key agent. In that case, give the command to use to retrieve agent keys, including tokens for required arguments (such as the username): 
    PubKeyAgent /usr/bin/sss_ssh_authorizedkeys %u