Managing NFS and NIS, 2nd Edition - Mike Eisler [162]
To receive NIS map updates from newkey or chkey, the master NIS server must be able to run rpc.ypupdated. On Solaris 8, this daemon is started as part of the /usr/lib/netsvc/yp/ypstart script, which in turn is started by the /etc/init.d/rpc boot script.
On every machine that will be using NFS/dh, make sure you are running the keyserv daemon. This process is used to cache private and common keys, and is also started out of /etc/init.d/rpc with lines of the form:
if [ -x /usr/sbin/keyserv -a \
-n "'/usr/bin/domainname 2>/dev/null'" ]; then
/usr/sbin/keyserv >/dev/msglog 2>&1
echo " keyserv\c"
fi
As you can see, keyserv will not start if there is no domain name established. Make sure keyserv can start, or you will not be able to create session keys, even if you have a valid public and private key pair in the publickey NIS maps.
Establishing a session key
When you log into a machine that is running NFS/dh, the password you supply to login is used to attempt to decrypt your encrypted private key (in the publickey map). If the login and RPC/DH passwords do not match you get errors like:
Password does not decrypt secret key (type = 192-0) for 'unix.23514@nesales.East.Sun.COM'.
Password does not decrypt any secret keys for unix.23514@nesales.East.Sun.COM.
The private key is given to the keyserv daemon, which caches it for generating common keys. The common keys are used to exchange session keys with NFS servers, as described earlier in this section. Therefore, the entire session key generation procedure goes like this:
You define a public and private key pair, using newkey or chkey. The private key is a large, random number; it is stored in the publickey map by encrypting it with your password.
When you log into a machine, your password is used to decrypt your private key. The private key is given to the keyserv daemon, where it is cached until you log out.
To access an NFS filesystem mounted with the sec=dh option, you must establish a common key with the NFS server. You form a common key using your private key and the public key for the NFS server. This is done automatically by the RPC/DH system.
From the common key, you derive a shared secret key by taking a subset of the bits of the common key. This secret key is used to encrypt a randomly generated session key, which is passed to the NFS server. All of your NFS requests to that server contain a timestamp encrypted with the session key. The server decrypts this timestamp to validate your NFS requests.
Note that you must supply your login password for the keyserv daemon to be given your private key. If you don't supply a password when you log into a machine — for example, you rlogin to another machine — then there is no way for the keyserv daemon to automatically receive your decrypted private key. To establish a session key in this situation, use the keylogin utility, which accepts your login password and uses it to decrypt your private key:
remote% keylogin
Password:
Note that if your login and RPC/DH passwords are different, whether you use rlogin or not, you must use keylogin to allow keyserv to see your private key. Or else you can use chkey -p to change your RPC/DH password to your login password.
Keys that are decrypted via keylogin are also passed to keyserv, where they remain until the user executes a keylogout. If you are going to be logging into nontrusted hosts, use keylogin to decrypt your key, and add keylogout to your .logout file (in your home directory) so that your key is destroyed when you log out.
You must reference the NIS passwd map in order for the automatic private key caching to occur. For proper operation of NFS/dh, do not put users in the local file /etc/passwd, or their encrypted private keys may become out-of-date when they change their local passwords but do not change the NIS-managed password used to encrypt the private key in the publickey map. On the