Managing Systems and Workgroups: A Guide for HP-UX System Administrators

Configuring a System
Using Distributed Systems Administration Utilities
Chapter 3 179
• Network port usage
• Encryption
• Checksum alerts
Key Exchange All the key exchange examples shown thus far have used scp to securely
transfer master server public key to the managed client and the
managed client’s public key to the master server. A scheme like this
provides the highest level of security but can be inconvenient in certain
situations. Other key distribution alternatives include the following:
• When connecting to a new client, cfrun has an interactive mode akin
to ssh, where the administrator is prompted to accept the remote
system’s key. For example:
cfrun(0): .......... [ Hailing remote-host.abc.xyz.com ] ..........
WARNING - You do not have a public key from host remote-host.abc.xyz.com =
12.345.678.90
Do you want to accept one on trust? (yes/no)
-> yes
cfrun:<master server name>: Trusting server identity and willing to accept key
from remote-host.abc.xyz.com=12.345.678.90
• For large numbers of new clients, this interactive mode can be
inefficient. cfrun supports a -T option which tells cfengine to trust
all new keys from the hosts listed in cfrun.hosts.
• cfservd.conf supports a TrustKeysFrom control clause. For
example:
control:
TrustKeysFrom = ( 128.39.89.76 ) # A trust host
TrustKeysFrom = ( 128.39.89.76/24 ) # A trusted subnet
The enumerated host or subnet addresses will be implicitly trusted
and their keys automatically accepted.
All of these key exchange alternatives should be used with extreme
caution and only in a secure environment where the LAN is trusted and
the remote hosts are trusted. Once a public key is accepted it will not be
updated unless it is deleted by hand from the master server’s
/var/opt/dsau/cfengine/ppkeys directory or manually replaced with
a new key.