Product SiteDocumentation Site

5.3. Managing Public SSH Keys for Users

OpenSSH uses public-private key pairs to authenticate users. A user attempts to access some network resource and presents its key pair. The first time the user authenticates, the administrator on the target machine has to approve the request manually. The machine then stores the user's public key in an authorized_keys file. Any time that the user attempts to access the resource again, the machine simply checks its authorized_keys file and then grants access automatically to approved users.
There are a couple of problems with this system:
On Fedora, the System Security Services Daemon (SSSD) can be configured to cache and retrieve user SSH keys so that applications and services only have to look in one location for user keys. Because SSSD can use FreeIPA as one of its identity information providers, FreeIPA provides a universal and centralized repository of keys. Administrators do not need to worry about distributing, updating, or verifying user SSH keys.
User SSH keys are added to user entries in FreeIPA, either when the user is created or by modifying the entry later. In a key file, such as a user's file, a key entry is identified by its type and then the key itself. For example, for an RSA key:
ssh-rsa ABCD1234==
Only the second part, the base 64-encoded key itself, is uploaded to the user entry.
The --sshpubkey option uploads the 64 bit-encoded public key to the user entry. For example:
[jsmith@server ~]$ ipa user-mod jsmith --sshpubkey="12345abcde="
With a real key, the key is longer and usually ends with an equals sign (=).
To upload multiple keys, pass a comma-separated list of keys with a single --sshpubkey option:
After uploading the user keys, configure SSSD to use FreeIPA as one of its identity domains and set up OpenSSH to use the SSSD tooling for managing user keys.