test

NFS Administration Guide

Administering the Secure NFS System

To use the Secure NFS system, all the computers you are responsible for must have a domain name. A domain is an administrative entity, typically consisting of several computers, that joins a larger network. If you are running NIS+, you should also establish the NIS+ name service for the domain. See Solaris Naming Setup and Configuration Guide.

You can configure the Secure NFS environment to use either Diffie-Hellman or Kerberos Version 4 authentication or a combination of the two. The System Administration Guide discusses these authentication services.

How to Set Up a Secure NFS Environment With DH Authentication

  1. Assign your domain a domain name, and make the domain name known to each computer in the domain.

    See the Solaris Naming Administration Guide if you are using NIS+ as your name service.

  2. Establish public keys and secret keys for your clients' users using the newkey or nisaddcred command, and have each user establish his or her own secure RPC password using the chkey command.

    Note -

    For information about these commands, see the newkey(1M), the nisaddcred(1M), and the chkey(1) man pages.

    When public and secret keys have been generated, the public and encrypted secret keys are stored in the publickey database.

  3. Verify that the name service is responding. If you are running NIS+, type the following: 


    # nisping -u
Last updates for directory eng.acme.com. :
Master server is eng-master.acme.com.
        Last update occurred at Mon Jun  5 11:16:10 1995

Replica server is eng1-replica-replica-58.acme.com.
        Last Update seen was Mon Jun  5 11:16:10 1995

    If you are running NIS, verify that the ypbind daemon is running.

  4. To verify that the keyserv daemon (the keyserver) is running, type the following: 


    # ps -ef | grep keyserv
root    100     1  16    Apr 11 ?      0:00 /usr/sbin/keyserv
root	  2215  2211   5  09:57:28 pts/0  0:00 grep keyserv

    If the daemon isn't running, to start the keyserver, type the following: 


    # /usr/sbin/keyserv

  5. Run keylogin to decrypt and store the secret key.

    Usually, the login password is identical to the network password. In this case, keylogin is not required. If the passwords are different, the users have to log in, and then do a keylogin. You still need to use the keylogin -r command as root to store the decrypted secret key in /etc/.rootkey.

    Note -

    You only need to run keylogin -r if the root secret key changes or /etc/.rootkey is lost.

  6. Edit the /etc/dfs/dfstab file and add the -sec=dh option to the appropriate entries (for Diffie-Hellman authentication). 


    share -F nfs -o sec=dh /export/home

  7. Edit the auto_master data to include -sec=dh as a mount option in the appropriate entries (for Diffie-Hellman authentication): 


    /home	auto_home	-nosuid,sec=dh
    Note -

    With Solaris 2.5 and earlier releases, if a client does not mount as secure a file system that is shared as secure, users have access as user nobody, rather than as themselves. With Version 2 on the Solaris 2.6 release, the NFS server will refuse access if the security modes do not match, unless -sec=none is included on the share command line. With version 3, the mode will be inherited from the NFS server, so there is no need for the clients to specify -sec=krb4 or -sec=dh. The users will have access to the files as themselves.

    When you reinstall, move, or upgrade a computer, remember to save /etc/.rootkey if you don't establish new keys or change them for root. If you do delete /etc/.rootkey, you can always type: 


    # keylogin -r

How to Set Up a Secure NFS Environment With KERB Authentication

  1. Edit the /etc/dfs/dfstab file and add the -sec=krb4 option to the appropriate entries. 


    # share -F nfs -o sec=krb4 /export/home

  2. Edit the auto_master data to include -sec=krb4 as a mount option. 


    /home	auto_home	-nosuid,sec=krb4
    Note -

    With Solaris 2.5 and earlier releases, if a client does not mount as secure a file system that is shared as secure, users have access as user nobody, rather than as themselves. With Version 2 on the Solaris 2.6 release, the NFS server will refuse access if the security modes do not match, unless -sec=none is included on the share command line. With version 3, the mode will be inherited from the NFS server, so there is no need for the clients to specify -sec=krb4 or -sec=dh. The users will have access to the files as themselves.