Hans Persson
2010-Nov-16 13:31 UTC
[CentOS] Still have problems with secure NFS and Kerberos
Both pc13267 and pc14113 run CentOS 5.5. On pc14113, my test user gets a home directory when logging in, but not on pc13267. But why? All logs below are from /var/log/messages. I have removed dates and stuff from the beginning of lines to make them more readable, and then grouped lines about the same thing from both machines.> pc13267 Using keytab file '/etc/krb5.keytab' > pc13267 INFO: Credentials in CC > 'MEMORY:/tmp/krb5cc_machine_IFM.LIU.SE' are good until > 1288959329> pc14113 getting credentials for client with uid 2038 for server > triangulum.ifm.liu.se > pc14113 CC file 'krb5cc_2038_R3Gzcw' being considered > pc14113 CC file 'krb5cc_2038_R3Gzcw' matches owner check and has > mtime of 1288949932For some reason, only the broken machine appears to look in /etc/krb5.keytab (or at least it's the only one admitting to doing it). /etc/krb5.conf looks the same on both machines. /etc/krb5.keytab has the same rights (root.root, 600) and size on both machines, and as far as I can tell no differences in content:> [root at pc13267 ~]# klist -k -e > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- ----------------------------------------------------------------- > 20 host/pc13267.ad.ifm.liu.se at IFM.LIU.SE (DES cbc mode withRSA-MD5)> 6 nfs/pc13267.ad.ifm.liu.se at IFM.LIU.SE (DES cbc mode with CRC-32)> [root at pc14113 ~]# klist -k -e > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- ----------------------------------------------------------------- > 3 nfs/pc14113.ad.ifm.liu.se at IFM.LIU.SE (DES cbc mode with CRC-32) > 3 host/pc14113.ad.ifm.liu.se at IFM.LIU.SE (DES cbc mode withRSA-MD5) There are no differences in /etc/pam.d/ between the machines (except that the working machine apart from the files it should have also has a system-auth-ac~, but I have a hard time imagining that to be significant).> pc13267 using MEMORY:/tmp/krb5cc_machine_IFM.LIU.SE as credentials > cache for machine creds > pc13267 using environment variable to select krb5 ccache > MEMORY:/tmp/krb5cc_machine_IFM.LIU.SE> pc14113 using FILE:/tmp/krb5cc_2038_R3Gzcw as credentials cache for > client with uid 2038 for server triangulum.ifm.liu.se > pc14113 using environment variable to select krb5 ccache > FILE:/tmp/krb5cc_2038_R3GzcwThe machine having problems save to memory, the working one to disk, and they use file names with a different structure. I suspect this to be relevant somehow, but I have no clue why they behave differently.> pc13267 creating context using fsuid 0 (save_uid 0) > pc13267 creating tcp client for server triangulum.ifm.liu.se > pc13267 creating context with server nfs at triangulum.ifm.liu.se> pc14113 creating context using fsuid 2038 (save_uid 0) > pc14113 creating tcp client for server triangulum.ifm.liu.se > pc14113 creating context with server nfs at triangulum.ifm.liu.seThe machine that works gets the uid right while the other one for some reason gets it to 0. Definitely wrong, but why?> pc13267 rpcsec_gss: gss_init_sec_context: (major) Unspecified GSS > failure. Minor code may provide more information - (minor) > Unknown code krb5 60 > pc13267 WARNING: Failed to create krb5 context for user with uid 0 > for server triangulum.ifm.liu.se > pc13267 WARNING: Failed to create krb5 context for user with uid 0 > with credentials cache MEMORY:/tmp/krb5cc_machine_IFM.LIU.SE for > server triangulum.ifm.liu.se > pc13267 WARNING: Failed to create krb5 context for user with uid 0 > with any credentials cache for server triangulum.ifm.liu.se> pc14113 DEBUG: serialize_krb5_ctx: lucid version! > pc14113 prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 > and length 8After this, things break down (which doesn't really surprise me). The question is, I guess, why the broken machine starts using uid 0 to begin with. There is also a difference in what tickets the user gets on the different machines.> [testson2 at pc13267 /]$ klist > Ticket cache: FILE:/tmp/krb5cc_2038_ch9xY3 > Default principal: testson2 at IFM.LIU.SE > > Valid starting Expires Service principal > 11/05/10 10:34:46 11/06/10 10:34:46 krbtgt/IFM.LIU.SE at IFM.LIU.SE > > > Kerberos 4 ticket cache: /tmp/tkt2038 > klist: You have no tickets cached(non-working)> pc14113:/home/testson2> klist > Ticket cache: FILE:/tmp/krb5cc_2038_R3Gzcw > Default principal: testson2 at IFM.LIU.SE > > Valid starting Expires Service principal > 11/05/10 10:38:52 11/06/10 10:38:52 krbtgt/IFM.LIU.SE at IFM.LIU.SE > 11/05/10 10:38:52 11/06/10 10:38:52nfs/triangulum.ifm.liu.se at IFM.LIU.SE> > > Kerberos 4 ticket cache: /tmp/tkt2038 > klist: You have no tickets cached(working) Ideas? I'm all out of 'em. Hans