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.

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 kno wn_ho sts file or for the remote user in autho ri zed _keys. Whenever that remote machine or user attempts to authenticate again, the local system simply checks the kno wn_ho sts or autho ri zed _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 kno wn_ho sts file is a triplet of the machine name, its IP address, and its public key:

server.example.com,172.16.0.1 ssh-rsa

AbcdEfg1234ZYX098776/AbcdEfg1234ZYX098776/AbcdEfg1234ZYX098776=

The kno wn_ho sts 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 kno wn_ho sts 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, 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 kno wn_ho sts 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 kno wn_ho sts file.

3.2 .5 .1 . Co nfiguring Ope nSSH t o Use SSSD fo r Ho st Ke ys

OpenSSH is configured in either a user-specific configuration file (~ /. ssh/co nfi g) or a system-wide configuration file (/etc/ssh/sshd _co nfi g). The user file has precedence over the system settings and the first obtained value for a parameter is used.

In order to manage host keys, SSSD has a tool, sss_ssh_kno wnho stspro xy, 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, /var/l i b/sss/pubco nf/kno wn_ho sts.

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] HOSTNAME [PROXY_COMMAND]

T ab le 3.4 . sss_ssh _kn o wn h o st sp ro xy O p t io n s

Sh o rt Arg u men t Lo n g Arg u men t Descrip t io n

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

P ro xyC o mmand =value. This option is used when running sss_ssh_kno wnho stspro xy 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.

Sh o rt Arg u men t Lo n g Arg u men t Descrip t io n

To use this SSSD tool, add or edit two parameters to the /etc/ssh/sshd _co nfi g or

~ /. ssh/co nfi g file:

Specify the command to use to connect to the SSH client (P ro xyC o mmand). This is the sss_ssh_kno wnho stspro xy, with the desired arguments and hostname.

Specify the location of the SSSD hosts file, rather than the default kno wn_ho sts file

(G l o bal Kno wnHo stsFi l e). The SSSD hosts file is /var/l i b/sss/pubco nf/kno wn_ho sts.

For example, this looks for public keys in the SSSD domain 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

3.2 .5 .2 . Co nfiguring Ope nSSH t o Use SSSD fo r Use r Ke ys

User keys are stored on a local system in the autho ri zed _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_autho ri zed _keys file.

OpenSSH is configured in either a user-specific configuration file (~ /. ssh/co nfi g) or a system-wide configuration file (/etc/ssh/sshd _co nfi g). The user file has precedence over the system settings and the first obtained value for a parameter is used.

In order to manage user keys, SSSD has a tool, sss_ssh_autho ri zed keys, 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_autho ri zed _keys, in the standard authorized keys format.

This tool has the format:

sss_ssh_authorizedkeys [-d sssd_domain] USER

T ab le 3.5. sss_ssh _au t h o riz ed keys O p t io n s

Sh o rt Arg u men t Lo n g Arg u men t Descrip t io n

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.

To configure OpenSSH to use SSSD for user keys, use the authorized key command. Specify the command to run to retrieve user keys and the user under whose account it is run. For example:

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys AuthorizedKeysCommandUser nobody