NFS, Kerberos and SSH
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.