Managing NFS and NIS, 2nd Edition - Mike Eisler [160]
share -o sec=dh:none,rw /export/home/thud
Within the NFS/dh system, a user without a valid public/private key pair becomes an anonymous user on the NFS server and is subject to the same access restrictions (discussed earlier in this chapter) that apply to the anonymous user nobody. To utilize NFS/dh without impairing a user's ability to do work, you must define public and private key pairs for trusted users and trusted hosts.
Public and private keys
Public and private keys are maintained in the publickey.byname NIS map, which is built from /etc/publickey on the master NIS server.[5] The only key that is defined by default is one for nobody, which is required for the anonymous user mapping. Public and encrypted secrets keys are contained in the /etc/publickey file, along with a unique identifier for the machine or user owning these keys.
unix.10461@nesales publickey:privatekey
The keys are long strings of hexadecimal digits, representing the encrypted key values. Obviously, the NIS map cannot contain the actual private keys, or the entire encryption mechanism would be baseless. Instead, the /etc/publickey file's private key field contains the user's private key, encrypted with the user's login password. For host entries, the private key is encrypted using the root password. The private keys themselves are large random numbers, just like the session key that is used by RPC/DH.
Identifiers in /etc/publickey are called netnames and take one of two forms:
unix.uid@NISdomain
unix.host@NISdomain
The first form is used for user keys; it defines a key valid in the current NIS domain. The host key is used to create a RPC/DH key for the superuser on the named host. No user key is required for root — only a host key.
The /etc/publickey file is changed by the RPC/DH utilities that create and manage key values. Because it contains encrypted key strings, it is not easily edited by the superuser, just as the password fields in /etc/passwd cannot be hand-edited. The publickey file should exist only on the NIS master server, or else users' private keys will become out of date when they change their passwords (and therefore change the encryption key used to store their private keys).
Creating keys
The superuser can add user keys (on the NIS master server) using newkey -u user. As root, run newkey with the user's login name:
nismaster# newkey -u stern
Adding new key for unix.1461@nesales.East.Sun.COM.
Enter stern's login password:
The password is used to encrypt the private key so that it can be safely placed in the publickey maps. Unfortunately, the user's existing password in the NIS passwd maps must be supplied, requiring you to know the user's password. This is fine if you are adding the user to passwd map anyway; he is therefore a new user. However, it is very inconvenient if you are adding NFS/dh security and have a large pool of existing users because:
You could change every user's login password to the same value. The problem with that is that for a period of time every user has the same password, and you can expect that some of your users will take malicious advantage of that.
You could change every user's login password to a unique value. The problem with that is you have to somehow securely get the new passwords to each user. Unless you have a secure email system like PGP or S/MIME installed that pretty much leaves you to walk to every user's office or telephone them. That you are considering NFS/dh suggests that you have a large user base. This is simply not practical.
Hopefully, a future version of Solaris will fix this so that you can supply any password to newkey. The way it would work is that you'd use the same RPC/DH password to encrypt every private key via newkey. You'd tell your users what the RPC/DH password is, and they would each use chkey -p (more on chkey later) to change the RPC/DH password to match