Skip to end of metadata
Go to start of metadata

Linux/SSH

There are a few different ways to use UW Kerberos on a Linux system, but the most common is for users to use their UW NetID and password when logging into a server via SSH. Which accounts can login is still defined via /etc/passwd. Key tips for configuration:

  • server must be on UW subnet; connections from outside UW network space is not permitted
  • server must have accurate time for Kerberos to work (recommend ntpd)
  • user accounts must be using UW NetIDs
  • homer.u.washington.edu can provide a working RedHat example to look at
  • copy /etc/krb5.conf from homer.u
  • verify kerberos user commands work before configuring services (kinit, klist, kdestroy).
  • openssh can use PAM to accept UW NetIDs and check them against the UW KDCs: configure pam_krb5.so in /etc/pam.d/sshd (homer.u has an example)
  • sshd can also be configured to accept GSSAPI auth for cases when user wants to authenticate with a kerberos ticket; if that is desired, the Remote Logins section of Stanford's Installing Kerberos on Red Hat may help.

To accept kerberos credentials, your server will need a service principal and keytab, which can be requested from help@u.washington.edu for each server you would like to kerberize.

Linux and NFS4

NFS4, as well as providing nfs ("network shares") can employ Kerberos for authentication, integrity, and privacy. Authentication is provided via the use of keytab files on the nfs server and clients, integrity checks can be performed on transmitted data, and privacy is done via keys to encrypt data over the network.

What follows is a quick "howto" for users of Debian Linux. It is valid for versions "etch" (or "oldstable"), "lenny" ("stable" as of spring 2009), and "squeeze" ("testing", the next stable version). Basic configuration will be emphasized, so that users may find ways to configure appropriate to other Linux distributions. Warning must be made about differences based on kernel version as well as the version of nfs-utils employed. Note will be made about MIT Kerberos 1.8 which is available as of March 2010, and at least one configuration option that may be required due to use of that version.

Assumptions made

For the purposes of this document, it is assumed that the user has servers and clients in part of a single third-level dns domain; here it will be referred to as *.bar.washington.edu . UW Tech Identity management team can allow appropriate people to have limited authority to get keytabs for hosts in their domain.

It will also be assumed that a kernel version >= 2.6.18 is being used.

/etc/krb5.conf

If one has already installed and tested use of a krb5.conf file for use with ssh and pam, then the same configuration file may be used. Ensure that your domain is part of the domain_realm section:

[domain_realm]
.u.washington.edu = u.washington.edu
.washington.edu = u.washington.edu
.bar.washington.edu = u.washington.edu

NFS4 'helper' daemons.

The NFS4 server and client will need to have several other processes running when using nfs4. For both server and client, ensure that /etc/default/nfs-common has the following enabled:

NEED_IDMAPD=yes
NEED_GSSD=yes

Other Linux distributions should enable these in the appropriate manner. A "ps" should list the processes:

statd     5980  0.0  0.1   2168   720 ?        Ss   Apr19   0:00 /sbin/rpc.statd
root      5989  0.0  0.1   4288   792 ?        Ss   Apr19   0:00 /usr/sbin/rpc.idmapd
root      5993  0.0  0.3   3336  1848 ?        Ss   Apr19   0:03 /usr/sbin/rpc.gssd

The NFS4 server should also have the svcgssd service running. The /etc/default/nfs-kernel-server file will have:

NEED_SVCGSSD=yes

and "ps" should display this, as well as mountd:

root     22568  0.0  0.3   5396  1656 ?        Ss   Apr19   0:00 /usr/sbin/rpc.svcgssd
root     22570  0.0  0.1   2312   696 ?        Ss   Apr19   0:00 /usr/sbin/rpc.mountd

Pseudofilesystem

The nfs4 server will employ use of a special mounted filesystem for exports. Say, for example, that user home directories and a common source code directory are to be exported. First, create a base mountpoint for export, and then points for the directories to be exported:

mkdir /export
mkdir /export/home
mkdir /export/code

Then, bind mount the home and code directories:

mount --bind /home  /export/home
mount --bind /usr/local/code  /export/code

In order to maintain these, you may edit /etc/fstab:

/home            /export/home        none        bind    0    0
/usr/local/code  /export/code        none        bind    0    0

Exports

Once the filesystem has been set up for exporting, one edits the /etc/exports file. Read the man page for options. Some options are necessary when Kerberos is to be used with nfs. It should be noted that kerberos is not required for nfs4, but it is a useful addition .

One example for exporting the filesystem above, using GSS and only authentication is as follows:

/export             gss/krb5(sec=krb5,insecure,rw,async,no_subtree_check,root_squash,fsid=0)
/export/home        gss/krb5(sec=krb5,insecure,rw,async,no_subtree_check,nohide,anonuid=65534,anongid=65534)
/export/code        gss/krb5(sec=krb5,insecure,rw,async,no_subtree_check,nohide,anonuid=65534,anongid=65534)

The first line is required. The portion gss/krb5 tells the nfs4 service that any clients will need to use some Kerberos method to authenticate, to mount the filesystem. This is where keytab files are needed (see below). The option "fsid=0" is required for kerberos exports;
note: Option "sec=krb5" is not available for some kernels and some versions of nfs-utils.

If one intends to add Kerberos integrity checking, substitute "krb5i" in the entries above. If encryption ("privacy") is desired, change the entries to use "krb5p".

Additional server and client configuration files.

Your system may have the two files (or analogous): /etc/idmapd.conf and /etc/gssapi_mech.conf The default version of the latter file in Debian is adequate. The former, idmapd.conf, should be edited, to have something like the following:

[General]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
Domain = bar.washington.edu

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
Method = nsswitch

Note that the Domain should match your domain. This is needed so that UID's and GID's will be honored on the client. Otherwise, all files will be mapped to the anonymous or "nobody" ID.

NFS4 Client mounts

The nfs client may mount the exported filesystem, employing /etc/fstab entries analogous to those in this example:

nfs-server1.bar.washington.edu:/home      /home              nfs4    sec=krb5p,rw,nodev,sync,proto=tcp 0 0
nfs-server2.bar.washington.edu:/code      /usr/local/code    nfs4    sec=krb5p,rw,nodev,sync,proto=tcp 0 0

note: The option "sec=krb5p" must match the option on the server. Thus if the server uses krb5i or krb5, the fstab option must be krb5i or krb5, respectively.

keytab files

After UW Tech Identity management has confirmed that you have authority to get or create keytab files for your *.bar.washington.edu domain, you use the "keyreq" command-line program to create those keytab files.

One can get a tarfile of the source code here: (also, see attachments link at top of page):  https://wiki.cac.washington.edu/download/attachments/15766959/keyreq-3.2.tar.gz (md5sum of the file is 43e7c11849c90a9bde0729badd91bdb9).

Configure and compile the program. Then use kinit with your UWNetid, and create your keytab files:

kinit memyselfi@u.washington.edu
keyreq -p nfs -f keytab.client  -h my-nfs-client.bar.washington.edu
keyreq -p nfs -f keytab.server  -h my-nfs-server.bar.washington.edu

Examining one of the keytab files, one should observe something like this:

klist -e -k keytab.server
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 nfs/ny-nfs-server.bar.washington.edu@u.washington.edu (DES cbc mode with CRC-32)

Scp the keytab files to your client and server, respectively. On Debian systems, the default filename is /etc/krb5.keytab

Restart the nfs processes, and try to mount the filesystems on the client.

Errors

There are a number of errors one may encounter in trying to use nfs4 with krb. One can start up the "helper" daemons with flags to increase log verbosity, and that can help. Also, manually mounting clients with -vvv options may assist.

There is an error that is reflected with various messages, which are not apparently related to the solution. If you are running a comparatively "new" version of the krb5 packages, you may need to add the following line to your /etc/krb5.conf file, in the [libdefaults] section:

allow_weak_crypto = true

MIT Kerberos 1.8 employs, by default, AES. Older versions employ DES. This line allows the different versions to play together nicely.

  • No labels