On Fri, Dec 2, 2016 at 9:28 AM, Lukas Hejtmanek <xhejtman@xxxxxxxxx> wrote: > On Fri, Dec 02, 2016 at 09:23:30AM -0500, Andy Adamson wrote: >> In your environment, UID 0 on the client machine (the machine >> credential in the host keytab) is mapped to nobody/nobody when >> accessing the NFS server > > well, ok, and this is what I want for users without kerberos tickets. Map them > to nobody/nogroup instead of error EPERM or EKEYEXPIRED. And I want this as an > option for administator of NFS client machine. >1) machine has NFS mounted /home using kerberos authentication OK > 2) user logs in, You mean, user ssh's into the NFS client machine and then runs kinit? Or does the user run kinit locally and then use ssh to forward the kerberos credentials? >sshd creates krb ticket ($HOME/.k5login Why do you use .k5login? from https://web.mit.edu/kerberos/krb5-1.13/doc/user/user_config/k5login.html The .k5login file, which resides in a user’s home directory, contains a list of the Kerberos principals. Anyone with valid tickets for a principal in the file is allowed host access with the UID of the user in whose home directory the file resides. One common use is to place a .k5login file in root’s home directory, thereby granting system administrators remote root access to the host via Kerberos. EXAMPLES Suppose the user alice had a .k5login file in her home directory containing just the following line: bob@xxxxxxxxxx This would allow bob to use Kerberos network applications, such as ssh(1), to access alice‘s account, using bob‘s Kerberos tickets. In a default configuration (with k5login_authoritative set to true in krb5.conf), this .k5login file would not let alice use those network applications to access her account, since she is not listed! With no .k5login file, or with k5login_authoritative set to false, a default rule would permit the principal alice in the machine’s default realm to access the alice account. >needs to be world >readable to allow kerberized access, e.g., using kerberos ticket) 1) Please explain what use the .k5login is in your environment. 2) IIUC only the initial ssh access works - the one that creates the $HOME/.k5login. All other accesses fail? 3) you mentioned that it's not ~/.k5login but ~/.krb5/config that is trying to be accessed. I can't find any doc on ~/.krb5/config. Is it just the replacement for .k5login? >ok, I did more testing. It seems that kinit does not search ~/.k5login but >~/.krb5/config. -->Andy > > -- > Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
