红帽全球峰会此内容没有您所选择的语言版本。
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=
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_hostsfile. - 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]
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
ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h
GlobalKnownHostsFile /var/lib/sss/pubconf/known_hostsConfiguring 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
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
Copy to Clipboard
Copied!
Toggle word wrap
Toggle overflow
These and further options are documented in the
/etc/ssh/sshd_config as follows:
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandRunAs nobody
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandRunAs nobodysshd_config(5) man page. Note that the sshd service must be restarted for any changes to take effect.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}