On Thu, Dec 8, 2016 at 4:50 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > On Thu, Dec 8, 2016 at 4:22 PM, Lukas Hejtmanek <xhejtman@xxxxxxxxx> wrote: >> On Thu, Dec 08, 2016 at 04:11:38PM -0500, Olga Kornievskaia wrote: >>> Why is "kinit" accessing ~/.krb5/config? Typically kinit will only >>> access /etc/krb5.conf. >>> >>> You are describing a catch-22 system. You want to create credentials >>> but to create credentials you need to access a file that is protected >>> by the credentials. This is a badly designed setup. >>> >>> kinit normally does not require access into something that is >>> protected by credentials gotten by kinit. >>> >>> Your solution is to provide your user with "kinit" that does not >>> access ~/.krb5/config. Please describe the need for that file and why >>> it can't be satisfied using machine global /etc/krb5.conf. >> >> debian heimdal 1.6~rc2+dfsg-9 opens ~/.krb5/config and ~/.rnd files. >> dunno why. >> >> MIT implementation does not seem to access $HOME. > > When you say "MIT implementation does not seem to access $HOME", do > you mean you've build kinit from MIT source and it works? If so, then > solution seems to be to bug debian folks to investigate what happened > to their kinit? > For instance RHEL/CentOS 7 had an issue where there patched OpenSSH > looked at .k5login file where normal ssh didn't and caused problems: > https://bugzilla.redhat.com/show_bug.cgi?id=1328243 > > I think that might be related to your other complaint with using ssh > keys to ssh. But at the same time I can see that what's going on here > is again somewhat un-kosher. If you placed .authorized_key under > something that only user with credentials can access, then you can't > get to it without having though credentials. You have mentioned that > "authorized_key" are readable but typically ~/.ssh had 700 permission > so sshd can't get to reading "authorized_keys" file. > > To summarize: i suggest that you check that if an upstream kinit (from > MIT) and upstream openssh have the problems you are describing. Sorry you said debian heimdal not MIT. If MIT works, I suggest bringing this issue up on the heimdal kerberos mailing list and describe the problem there. -- 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