• Choose a category
• All
• Classic-Fiction

You cannot achieve the ideal, but you can come close. What you can do is create a template user login, with a unique UID (let's use 66666 for this example) and GID, and assign it a password that you intend to publish to all your users. Make sure that template has a shell of /dev/null in the passwd map, so that no one can log in as template. Now create keys for template :

nismaster# newkey -u template

Adding new key for unix.66666@nesales.East.Sun.COM.

Enter template's login password:

If you look at the /etc/publickey on host nismaster you should see something like:

unix.66666@nesales.East.Sun.COM 74365f4e03701cf96de938a59baa39f1039ada407b4ab3a3:9b7130a3f38c6e86f431f81ce1cf64b5e59991d3d5d1ce0596fd5167cb878b51

The netname of template is unix.66666@nesales.East.Sun.COM. Each of your users will have a similar netname, except for the number between the unix prefix, and the @nesale.East.Sun.COM suffix. The last long hexadecimal number after the colon (:) is user template 's private key, encrypted with template 's login password.

Now for each user, make a copy of template 's entry in the /etc/publickey file, but change the netname to match the user. Let's say that your set of users is stern, labiaga, and mre, with UIDs of 1461, 15124, and 23154, respectively. You then edit the /etc/publickey file to look like:

unix.66666@nesales.East.Sun.COM 74365f4e03701cf96de938a59baa39f1039ada407b4ab3a3:9b7130a3f38c6e86f431f81ce1cf64b5e59991d3d5d1ce0596fd5167cb878b51

unix.1461@nesales.East.Sun.COM 74365f4e03701cf96de938a59baa39f1039ada407b4ab3a3:9b7130a3f38c6e86f431f81ce1cf64b5e59991d3d5d1ce0596fd5167cb878b51

unix.15124@nesales.East.Sun.COM 74365f4e03701cf96de938a59baa39f1039ada407b4ab3a3:9b7130a3f38c6e86f431f81ce1cf64b5e59991d3d5d1ce0596fd5167cb878b51

unix.23514@nesales.East.Sun.COM 74365f4e03701cf96de938a59baa39f1039ada407b4ab3a3:9b7130a3f38c6e86f431f81ce1cf64b5e59991d3d5d1ce0596fd5167cb878b51

You now want to push the publickey file changes into the publickey NIS maps:

nismaster# cd /var/yp

nismaster# make publickey

updated publickey

pushed publickey

You have now almost effortlessly fully populated the publickey maps, but each entry has the same public key, same private key, and the same password. This is not what you want for the long term. So now you tell your users to expend some effort. Each user should be told to:

Change his or her RPC/DH password that the private key is encrypted with (changing the password to the user's login password is recommended).

Change his or her public and private key.

Here are the instructions we give to each user:

client% chkey -p

Updating nis publickey database.

Reencrypting key for 'unix.1461@nesales.East.Sun.COM'.

Please enter the Secure-RPC password for stern:

Please enter the login password for stern:

Sending key change request to nismaster ...

client% chkey

Updating nis publickey database.

Generating new key for 'unix.1461@nesales.East.Sun.COM'.

Please enter the Secure-RPC password for stern:

Sending key change request to nismaster ...

The first chkey command invocation reencrypts his private key with his login password. The second chkey invocation generates a brand new and unique private key and public key pair.

If the user supplies an invalid password, no password or key will be created. If the user's password is valid, and the NIS master server is receiving key updates, the key will be added to, or modified in, the NIS publickey maps. Both the chkey and newkey utilities update the /etc/publickey file on the NIS master server.

To ensure that your users are following the chkey instructions, you can check the publickey.byname map to see if both the private key and the public key fields of each user have changed, by comparing them to that of the user template.

The only way to create host keys (for superuser verification) is to use newkey -h as root :

# newkey -h bitatron

Adding new key for unix.bitatron@nesales.East.Sun.COM.

New password:

You