I'm an NFS guy, learned it a bit at uwisc and then a lot more at Sun. But Sun didn't do the Kerberos stuff, at least while I was there. Didn't Kerberos come from MIT? If so, I bet anything that Ted Ts'o would know the details. My guess is it was part of project athena and I think that overlaps with Ted. Yo, Ted, Merry Christmas, what about this Kerberos authentication stuff? :) On Tue, Dec 25, 2018 at 05:49:49PM -0700, Grant Taylor via TUHS wrote: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

First: Thank you for the very detailed response Ted. I hope that my response is worth while. On 12/25/18 9:49 PM, Theodore Y. Ts'o wrote: Okay. My (limited) understanding is that I have that functionality with Kerberos (for authentication) and LDAP (for directory information). Please correct me if that's incorrect. It's my understanding that Project Athena used Hesiod data stored in DNS in place of what I'm storing in LDAP. That is both Hesiod and LDAP store information, meta data, about accounts, which is typically stored in /etc/passwd. The important distinction is that password / authentication information is decidedly NOT stored in DNS or LDAP. Instead, authentication is solely in the Kerberos realm. (Pun is somewhat intended.) Is that correct? I'm taking that to be the Hesiod equivalent of "getent passwd tytso". Is that correct? If I'm understanding you correctly, you're stating that Kerberos authenticated NFS uses the uid & gid learned via Kerberos authentication and ignoring the purported uid & gid from the NFS RPC. This makes sense. It also removes the need to trust the NFS RPC which was inherently dependent on trusting the NFS client machine. I hadn't thought about this before. I guess client side might be an optimization for clients. But I would only trust server side. (Likewise with client side JavaScript compared to server side $LanguageDejure.) ACK Okay. I'm going to have to think about that more. I wonder if that means that my "getent passwd" method mentioned above is flawed. Hum. I have no problem accepting that Kerberized NFS wants to not blindly trust the uid & gid that the NFS client claims. But I would think that an authenticated root account would satisfy Kerberized NFS and allow uid & gid 0. As in we trust the Kerberos authentication, and retrieved uid & gid 0 from the directory (Hesiod or LDAP). Thus I would expect a trusted uid & gid of 0 to be allowed to access files despite what the file system permissions say. Though, as sure as I type that, I wonder about "an authenticated root account". As in are there multiple? Or is there a common shared single root account with uid & gid 0. - I don't know what should be done there. I think a single common root account would match a single common tytso account. But I can see the security advantage of not having a single common root account. The use case that I'm working with, which works perfectly fine with sec=sys. /home is mounted off of an export with no_root_squash. So, sshd running as root can access /home/tytso/.ssh/authorized_keys. But, this doesn't seem to work when I use sec=krb5{,i,p}. It seems as if root can't access files that standard file system permissions prohibit access to. As if root_squash was in effect. I /think/ that root has a valid Kerberos TGT, thus can properly authenticate to NFS and as such /should/ be able to access /home/tytso/.ssh/authorized_keys. Perhaps I am making a bad assumption in thinking the system's keytab is sufficient to allow root to authenticate to Kerberos. - I'm relatively new to Kerberos and still learning the ropes. I'm not trying to blindly have root access files that it doesn't have permission to. I'm perfectly happy to have root authenticate to Kerberos and have the proper tickets to satisfy NFS. I /thought/ I was doing exactly that. Perhaps I'm mistaken. Hum. The idea of mapping host/$FQDN@$REALM to uid 0 sounds like it might be part of what I /think/ I am wanting and that I should do some more reading about it. I could also be mistaken in thinking that I want (properly authenticated) root to have access like I'm describing. Understandable. That makes sense. Especially in that situation. This is also one of the reasons that I'm questioning if my logic about allowing an authenticated root having access. But, I'm not (yet) aware of another way to enable sshd, running as root, to access ~/.ssh/authorized_keys files from an NFS export. I'd be happy to hear about other ways. Aside: I'm actually authenticating to SSH using Kerberos via GSSAPI. I'm wanting access to ~/.ssh/authorized_keys file for another PAM module for something else. (This works perfectly fine with sec=sys or local non-NFS files.) LOL I get it. Ya. Knowing the ""secret really take the wind out of the sails of trying to learn the ""secret. I think I get the reason why you say that and why you did what you did. That just leaves me looking for another solution to needing to access ~/.ssh/authorized_keys with 0600 permissions. -- Grant. . . . unix || die

On 12/25/18 5:49 PM, Grant Taylor via TUHS wrote: After much toil and tribulation, I've managed to get things working. I've found that no_root_squash is still equally as applicable in Kerberized NFS as it is in non-Kerberized NFS. no_root_squash actually still does the same thing in Kerberized NFS. I figured out (by grinding through possible options) that I needed to do the following: Add a new principal, root/host.sub.domain.tld, and add it to host's (system wide) keytab file. I also needed to configure and enable translations in the /etc/idmapd.conf file /on/ /the/ /NFS/ /server/. --8<-- [Static] root/host.sub.domain.tld = root [Translation] GSS-Methods = static,nsswitch -->8-- Hopefully this will help someone trying to do something similar in the future. Now, services running as root (sshd) are able to read files (authorized_keys) that root doesn’t have permission to read (owned by user and 0600) on an NFS mount (/home) that is using Kerberos authentication. -- Grant. . . . unix || die