Este contenido no está disponible en el idioma seleccionado.

10.4. Managing Public SSH Keys for Hosts


OpenSSH uses public keys to authenticate hosts. One machine attempts to access another machine and presents its key pair. The first time the host authenticates, the administrator on the target machine has to approve the request manually. The machine then stores the host's public key in a known_hosts file. Any time that the remote machine attempts to access the target machine again, the target machine simply checks its known_hosts file and then grants access automatically to approved hosts.
There are a few problems with this system:
  • The known_hosts file stores host entries in a triplet of the host IP address, hostname, and key. This file can rapidly become out of date if the IP address changes (which is common in virtual environments and data centers) or if the key is updated.
  • SSH keys have to be distributed manually and separately to all machines in an environment.
  • Administrators have to approve host keys to add them to the configuration, but it is difficult to verify either the host or key issuer properly, which can create security problems.
On Red Hat Enterprise Linux, the System Security Services Daemon (SSSD) can be configured to cache and retrieve host SSH keys so that applications and services only have to look in one location for host keys. Because SSSD can use Identity Management as one of its identity information providers, Identity Management provides a universal and centralized repository of keys. Administrators do not need to worry about distributing, updating, or verifying host SSH keys.

10.4.1. About the SSH Key Format

When keys are uploaded to the IdM entry, the key format can be either an OpenSSH-style key or a raw RFC 4253-style blob. Any RFC 4253-style key is automatically converted into an OpenSSH-style key before it is imported and saved into the IdM LDAP server.
The IdM server can identify the type of key, such as an RSA or DSA key, from the uploaded key blob. However, in a key file such as ~/.ssh/known_hosts, a key entry is identified by the hostname and IP address of the server, its type, then lastly the key itself. For example:
host.example.com,1.2.3.4 ssh-rsa AAA...ZZZ==
This is slightly different than a user public key entry, which has the elements in the order type key== comment:
"ssh-rsa ABCD1234...== ipaclient.example.com"
All three parts from the key file can be uploaded to and viewed for the host entry. In that case, the host public key entry from the ~/.ssh/known_hosts file needs to be reordered to match the format of a user key, type key== comment:
ssh-rsa AAA...ZZZ== host.example.com,1.2.3.4
The key type can be determined automatically from the content of the public key, and the comment is optional, to make identifying individual keys easier. The only required element is the public key blob itself.

10.4.2. About ipa-client-install and OpenSSH

The ipa-client-install script, by default, configures an OpenSSH server and client on the IdM client machine. It also configures SSSD to perform host and user key caching. Essentially, simply configuring the client does all of the configuration necessary for the host to use SSSD, OpenSSH, and Identity Management for key caching and retrieval.
If the SSH service is enabled with the client installation (which is the default), then an RSA key is created when the ssh service is first started.

Note

When the machine is added as an IdM client using ipa-client-install, the client is created with two SSH keys, RSA and DSS.
There is an additional client configuration option, --ssh-trust-dns, which can be run with ipa-client-install and automatically configures OpenSSH to trust the IdM DNS records, where the key fingerprints are stored.
Alternatively, it is possible to disable OpenSSH at the time the client is installed, using the --no-sshd option. This prevents the install script from configuring the OpenSSH server.
Another option, --no-dns-sshfp, prevents the host from creating DNS SSHFP records with its own DNS entries. This can be used with or without the --no-sshd option.

10.4.3. Uploading Host SSH Keys Through the Web UI

  1. The key for a host can probably be retrieved from a ~/.ssh/known_hosts. For example:
    server.example.com,1.2.3.4 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApvjBvSFSkTU0WQW4eOweeo0DZZ08F9Ud21xlLy6FOhzwpXFGIyxvXZ52+siHBHbbqGL5+14N7UvElruyslIHx9LYUR/pPKSMXCGyboLy5aTNl5OQ5EHwrhVnFDIKXkvp45945R7SKYCUtRumm0Iw6wq0XD4o+ILeVbV3wmcB1bXs36ZvC/M6riefn9PcJmh6vNCvIsbMY6S+FhkWUTTiOXJjUDYRLlwM273FfWhzHK+SSQXeBp/zIn1gFvJhSZMRi9HZpDoqxLbBB9QIdIw6U4MIjNmKsSI/ASpkFm2GuQ7ZK9KuMItY2AoCuIRmRAdF8iYNHBTXNfFurGogXwRDjQ==
    If necessary, generate a host key. When using the OpenSSH tools, make sure to use a blank passphrase and to save the key to a different location than the user's ~/.ssh/ directory, so it will not overwrite any existing keys.
    [jsmith@server ~]$ ssh-keygen -t rsa -C "server.example.com,1.2.3.4"
    Generating public/private rsa key pair.
    Enter file in which to save the key (/home/jsmith/.ssh/id_rsa): /home/jsmith/.ssh/host_keys
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /home/jsmith/.ssh/host_keys.
    Your public key has been saved in /home/jsmith/.ssh/host_keys.pub.
    The key fingerprint is:
    4f:61:ee:2c:f7:d7:da:41:17:93:de:1d:19:ac:2e:c8 server.example.com
    The key's randomart image is:
    +--[ RSA 2048]----+
    |              .. |
    |               .+|
    |          o   .* |
    |         o . .. *|
    |        S + .  o+|
    |         E . .. .|
    |        . = .  o |
    |         o .  ..o|
    |            .....|
    +-----------------+
  2. Copy the public key from the key file. The full key entry has the form hostname,IP type key==. Only the key== is required, but the entire entry can be stored. To use all elements in the entry, rearrange the entry so it has the order type key== [hostname,IP]
    [jsmith@server ~]$ cat /home/jsmith/.ssh/host_keys.pub
    						
    ssh-rsa AAAAB3NzaC1yc2E...tJG1PK2Mq++wQ== server.example.com,1.2.3.4
  3. Open the Identity tab, and select the Hosts subtab.
  4. Click the name of the host to edit.
  5. In the Host Settings area of the Settings tab, click the SSH public keys: Add link.
  6. The UI opens a new link, New: key not set Show/Set key. Click the Show/Set key link.
  7. Paste in the public key for the host, and click the Set button.
    The SSH public keys field now shows New: key set. Clicking the Show/Set key link opens the submitted key.
  8. To upload multiple keys, click the Add link below the list of public keys, and upload the other keys.
  9. When all the keys have been submitted, click the Update link at the top of the host's page to save the changes.
When the public key is saved, the entry is displayed as the key fingerprint, the comment (if one was included), and the key type[4].
Saved Public Key

Figure 10.1. Saved Public Key

After uploading the host keys, configure SSSD to use Identity Management as one of its identity domains and set up OpenSSH to use the SSSD tooling for managing host keys.
After uploading the host keys, configure SSSD to use Identity Management as one of its identity domains and set up OpenSSH to use the SSSD tooling for managing host keys. This is covered in the Red Hat Enterprise Linux Deployment Guide.

10.4.4. Adding Host Keys from the Command Line

Host SSH keys are added to host entries in IdM, either when the host is created using host-add or by modifying the entry later.

Note

RSA and DSS host keys are created by the ipa-client-install command, unless the SSH service is explicitly disabled in the installation script.
  1. Run the host-mod command with the --sshpubkey option to upload the 64 bit-encoded public key to the host entry.
    Adding a host key also changes the DNS SSHFP entry for the host, so also use the --updatedns option to update the host's DNS entry.
    For example:
    [jsmith@server ~]$ ipa host-mod --sshpubkey="ssh-rsa 12345abcde==" --updatedns host1.example.com
    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:
    --sshpubkey="12345abcde==,key2==,key3=="

    Note

    A host can have multiple public keys.
  2. After uploading the host keys, configure SSSD to use Identity Management as one of its identity domains and set up OpenSSH to use the SSSD tooling for managing host keys. This is covered in the Red Hat Enterprise Linux Deployment Guide.

10.4.5. Removing Host Keys

Host keys can be removed once they expire or are no longer valid.
To remove an individual host key, it is easiest to remove the key through the web UI:
  1. Open the Identity tab, and select the Hosts subtab.
  2. Click the name of the host to edit.
  3. Open the Host Settings area of the Settings tab.
  4. Click the Delete link by the fingerprint of the key to remove.
  5. Click the Update link at the top of the host's page to save the changes.
The command-line tools can be used to remove all keys. This is done by running ipa host-mod with the --sshpubkey= set to a blank value; this removes all public keys for the host. Also, use the --updatedns option to update the host's DNS entry. For example:
[jsmith@server ~]$ kinit admin
[jsmith@server ~]$ ipa host-mod --sshpubkey= --updatedns host1.example.com


[4] The key type is determined automatically from the key itself, if it is not included in the uploaded key.
Red Hat logoGithubRedditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

© 2024 Red Hat, Inc.