LDAP-UX Client Services B.05.00 Administrator's Guide

• Define authentication and access control, such that a limited set of privileged users will have
the ability to manage host and ssh key data in the directory server.
• Install a CA or server certificate in the /etc/opt/ldapux/cert8.db file. This can be done
using /opt/ldapux/bin/certutil, or by installing the auto-generated LDAP-UX domain
CA depot (created with the guided installation).
• Configure LDAP-UX on all host clients. ssh communicates through LDAP-UX to securely
connect with the directory server and discover the location of the host and key information.
Be sure to configure SSL, which is the default with a guided installation.
• Configure the ssh client to use LDAP for key discovery. This simply requires enabling the
feature by setting flags in the /opt/ssh/etc/ssh_config and /opt/ssh/etc/
sshd_config files. HP Secure Shell A.05.50 or higher is required.
• Optionally, define a central ssh configuration, using the LDAP-UX central configuration
service. This service will allow you to centrally manage ssh configuration and will distribute
that configuration to all LDAP-UX enabled clients that are part of the same LDAP-UX
domain.
6.2.1 Host repository
To centrally manage host keys, a central repository must be defined to store that information.
For clients to discover host keys, they must know the location of the repository as well as trust
that repository and the data managed within it. The following subsections describe how ssh
clients can identify and trust that repository.
6.2.2 Data Location
To centrally manage ssh keys for hosts, information about these hosts must be stored in the
directory server. Choose a location in the directory information tree (DIT) where these hosts will
reside. That location should be within the scope of the base DN specified when you configured
LDAP-UX (see “Installing and configuring LDAP-UX Client Services” (page 21)). If you have
used a guided installation to create your directory server instance, that location will be
ou=hosts,suffix, where suffix is the root of your directory server data. If you have already
configured LDAP-UX, then you can use the ldapcfinfo tool to determine where LDAP-UX
believes host information should be located.
Example:
# /opt/ldapux/bin/ldapcfinfo -t hosts -b
ou=Hosts,dc=mydomain,dc=example,dc=com
If the base DN discovered above is not the desired location within the directory tree, you can
reconfigure the LDAP-UX profile using the steps outlined in Section 5.12 (page 183).
6.2.3 Trust
Trust between an ssh client and a remote host depends on the ability of the client to validate the
identity of the remote host, and vice versa. As previously mentioned, this requires the ssh client
to have access to the public key of the remote host. It needs that key to validate the key presented
by the remote host when the initial connection is made. Traditionally, this key is stored in the
known_hosts file on the local client’s host. This file is under the control of the user himself, in
the ~/.ssh/known_hosts file, or a system administrator might have put a list of hosts in the
/opt/ssh/etc/ssh_known_hosts file. This file is assumed to be secured. Proper files system
permissions are set to prevent unauthorized modification.
When the ssh public key is managed in the directory server, the integrity of the sshPublicKey
attribute must be assured to achieve that same level of trust. Just as the user can trust his own
known_hosts file or the ssh known_hosts file set up by his administrator, the user must also
be able to trust the integrity of the sshPublicKey attribute when managed in the directory
server. Trusting the ssh key repository requires that the identity of the directory server can be
validated, the data in the directory server cannot be modified by unauthorized users, and the
6.2 Setting up the key management domain 197