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_hosts
file or for the remote user in authorized_keys
. Whenever that remote machine or user attempts to authenticate again, the local system 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 host name, 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 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_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 Identity Management actually stores the public keys and host information.
Note
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
known_hosts
file.
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
/var/lib/sss/pubconf/known_hosts
file. - 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]
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, %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 thesss_ssh_knownhostsproxy
, with the desired arguments and host name. - Specify the location of the SSSD hosts file (
GlobalKnownHostsFile
).
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_authorizedkeys
tool and are not stored in a file.
To configure
sshd
to read a user's public keys from an external program, in this case the sss_ssh_authorizedkeys
tool, use the AuthorizedKeysCommand directive in the /etc/ssh/sshd_config
file.
The
sss_ssh_authorizedkeys
tool can be used to acquire SSH public keys from the user entries in the Identity Management (IPA) domain and output them in OpenSSH authorized_keys
format. The command has the following format:
sss_ssh_authorizedkeys [-d sssd_domain] USER
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, %u . | |
-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
/etc/ssh/sshd_config
as follows:
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandRunAs nobodyThese and further options are documented in the
sshd_config(5)
man page. Note that the sshd
service must be restarted for any changes to take effect.