NFS, Kerberos and SSH

From: Lexi Winter <lexi_at_le-fay.org>
Date: Thu, 29 Feb 2024 03:19:27 UTC
(Rick: i hope you don't mind the Cc:, but i thought you might be able to
offer some input here since you've helped me with Kerberized NFS in the
past.)

hi list,

i recently ran into a problem with NFS, Kerberos and SSH.  the system
configuration was like this:

- Kerberos configured with a host ticket in /etc/krb5.keytab
- sshd configured to use Kerberos with GSSAPI authentication enabled
- Kerberized NFS configured with automountd(8) to manage /home

/etc/auto_master:

/home		auto_home

/etc/auto_home:

*	-nfsv4,sec=krb5p,gssname=host hemlock.eden.le-fay.org:/home/&

the problem is this: when a user tries to log in via ssh, SSH
authenticates the user's Kerberos ticket, then it tries to open a file
called $HOME/.k5login.  however, because it does this without the user's
Kerberos ticket, the open fails with EIO, and sshd rejects the login
("authentication failed"):

from sshd -ddd:

NFSv4 error WrongSec: You probably need a Kerberos TGT
fstatat(AT_FDCWD,"/home/lexi/.k5login.d",0x2792356252b0,AT_SYMLINK_NOFOLLOW) ERR#5 'Input/output error'
Failed gssapi-with-mic for lexi from 2001:8b0:aab5:106:3::10 port 63175 ssh2

using a forwardable ticket (ssh -K) does *not* fix the problem, because
sshd is not running with the user's Kerberos credentials at this point.

this behaviour is discussed in this upstream Heimdal ticket:
https://github.com/heimdal/heimdal/issues/368

the upshot is that it's impossible to allow users to log in via
Kerberized SSH while also using Kerberized NFS to mount their home
directories, even though this seems like a configuration that would be
both desirable and common in any environment using Kerberos.

so my first question is: is there a solution / workaround for this?

and my second question is: if the answer is no, what if i provided a
patch for the NFS client to add a new option, like 'fallbackgssname',
which would work like 'allgssname' except that it would only use the
host's Kerberos ticket if there isn't already an existing user-specific
Kerberos ticket?  i haven't looked at how difficult this would be to
implement, but it seems like an obvious solution that would fix this
problem.

	regards, lexi.