5

** Edit: ** I am not using Sabayon Linux anymore and this problem didn't occur on other distributions. I suggest to close this question.

Update: I realized that because of bad hosts file, both machines resolves their local names to 127.0.0.1 instead of their LAN IP Address. Once I changed it and tried to mount, the client shows:

mount.nfs4: timeout set for Sun Mar 31 10:33:38 2013
mount.nfs4: trying text-based options 'sec=krb5,addr=192.168.10.200,clientaddr=192.168.10.103'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting shakuras.darwinia.lan:/

Looking at the client's syslog:

rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa36cb0 data 0x7fffcfa36b80
rpc.idmapd[13036]: New client: 1a
rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa321f0 data 0x7fffcfa320c0
rpc.gssd[13067]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt1a)
rpc.gssd[13067]: handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2 '
rpc.gssd[13067]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt1a)
rpc.gssd[13067]: process_krb5_upcall: service is '*'
rpc.idmapd[13036]: Opened /var/lib/nfs/rpc_pipefs//nfs/clnt1a/idmap
rpc.gssd[13067]: Full hostname for 'server.domain' is 'server.domain'
rpc.gssd[13067]: Full hostname for 'client.domain' is 'client.domain'
rpc.gssd[13067]: No key table entry found for CLIENT$@REALM while getting keytab entry for 'CLIENT$@REALM'
rpc.gssd[13067]: No key table entry found for root/client.domain@REALM while getting keytab entry for 'root/client.domain@REALM'
rpc.gssd[13067]: Success getting keytab entry for 'nfs/client.domain@REALM'
rpc.gssd[13067]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_REALM' are good until 1364748098
rpc.gssd[13067]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_REALM' are good until 1364748098
rpc.gssd[13067]: using FILE:/tmp/krb5cc_machine_REALM as credentials cache for machine creds
rpc.gssd[13067]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_REALM
rpc.gssd[13067]: creating context using fsuid 0 (save_uid 0)
rpc.gssd[13067]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - No Kerberos credentials available
rpc.gssd[13067]: WARNING: Failed while limiting krb5 encryption types for user with uid 0
rpc.gssd[13067]: WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_REALM for server server.domain
rpc.gssd[13067]: WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server server.domain
rpc.gssd[13067]: Full hostname for 'server.domain' is 'server.domain'
rpc.gssd[13067]: Full hostname for 'client.domain' is 'client.domain'
rpc.gssd[13067]: No key table entry found for CLIENT$@REALM while getting keytab entry for 'CLIENT$@REALM'
rpc.gssd[13067]: No key table entry found for root/client.domain@REALM while getting keytab entry for 'root/client.domain@REALM'
rpc.gssd[13067]: Success getting keytab entry for 'nfs/client.domain@REALM'
rpc.gssd[13067]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_REALM' are good until 1364748098
rpc.gssd[13067]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_REALM' are good until 1364748098
rpc.gssd[13067]: using FILE:/tmp/krb5cc_machine_REALM as credentials cache for machine creds
rpc.gssd[13067]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_REALM
rpc.gssd[13067]: creating context using fsuid 0 (save_uid 0)
rpc.gssd[13067]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - No Kerberos credentials available
rpc.gssd[13067]: WARNING: Failed while limiting krb5 encryption types for user with uid 0
rpc.gssd[13067]: WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_REALM for server server.domain
rpc.gssd[13067]: WARNING: Failed to create machine krb5 context with any credentials cache for server server.domain
rpc.gssd[13067]: doing error downcall
rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa36cb0 data 0x7fffcfa36b80
rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa36cb0 data 0x7fffcfa36b80
rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa36cb0 data 0x7fffcfa36b80
rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa36cb0 data 0x7fffcfa36b80
rpc.gssd[13067]: dir_notify_handler: sig 37 si 0x7fffcfa36cb0 data 0x7fffcfa36b80
rpc.gssd[13067]: destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt1a
rpc.idmapd[13036]: Stale client: 1a
rpc.idmapd[13036]:  -> closed /var/lib/nfs/rpc_pipefs//nfs/clnt1a/idmap

The server's syslog only shows:

krb5kdc[31142]: AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.10.103: NEEDED_PREAUTH: nfs/client.domain@REALM for krbtgt/REALM@REALM, Additional pre-authentication required

Client ktutil:

ktutil 
ktutil:  rkt /etc/krb5.keytab 
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3   nfs/client.domain@REALM

Server ktutil:

ktutil:  rkt /etc/krb5.keytab 
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    2   nfs/server.domain@REALM

Previous Post:

I'm trying to setup a secure NFS4 server using Kerberos. My network has a local DNS server. Both the client and the server can (reverse) lookup each other. At first, I followed this tutorial:

http://wiki.paraf.in/~parafin/linux/nfs4krb5

Since I'm using Sabayon Linux, which is gentoo based. I then realized that the syntax for the NFS exported file might be incorrect. Currently, when NFS exports is set up like this:

/export gss/krb5p(rw,insecure,async,no_root_squash,no_subtree_check)

The client can mount the remote filesystem. However, trying to change it to Kerberos:

/export gss/krb5(rw,insecure,async,no_root_squash,no_subtree_check)

And the client cannot mount the filesystem anymore. The mount command:

mount -o sec=krb5 -t nfs4  server.domain:/export /mnt/nfs/ -vvv

seems to hang forever. After a couple of minutes I can see the client's dmesg:

nfs: server server.domain not responding, timed out

The command stills hangs, though. Some additional facts:

  1. The KDC and the NFS server are the same machine
  2. idmap, rpc.svcgssd and nfs runs on the server
  3. idmap, rpc.gssd and nfs runs on the client
  4. The kernel has support for gss rpc
  5. Keytab files for both client and the server are placed in /etc/krb5.keytab, readable only by root

Trying to increase verbosity on both sides, when I connect I can see: Server:

rpc.svcgssd[23856]: sname = nfs/client.domain@REALM
rpc.svcgssd[23856]: DEBUG: serialize_krb5_ctx: lucid version!
rpc.svcgssd[23856]: prepare_krb5_rfc4121_buffer: protocol 1
rpc.svcgssd[23856]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32
rpc.svcgssd[23856]: doing downcall
rpc.svcgssd[23856]: mech: krb5, hndl len: 4, ctx len 52, timeout: 1364700223 (33977 from now), clnt: nfs@client.domain, uid: -1, gid: -1, num aux grps: 0:
rpc.svcgssd[23856]: sending null reply
rpc.svcgssd[23856]: writing message: [BINARY MESSAGE]
rpc.svcgssd[23856]: finished handling null request
rpc.svcgssd[23856]: entering poll

Client:

rpc.gssd[20295]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt64)
rpc.gssd[20295]: handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,23,3,1,2 '
rpc.gssd[20295]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt64)
rpc.gssd[20295]: process_krb5_upcall: service is '*'
rpc.gssd[20295]: Full hostname for 'server.domain' is 'server.domain'
rpc.gssd[20295]: Full hostname for 'localhost' is 'localhost'
rpc.gssd[20295]: No key table entry found for CLIENT$@REALM while getting keytab entry for 'CLIENT$@REALM'
rpc.gssd[20295]: No key table entry found for root/localhost@REALM while getting keytab entry for 'root/localhost@REALM'
rpc.gssd[20295]: No key table entry found for nfs/localhost@REALM while getting keytab entry for 'nfs/localhost@REALM'
rpc.gssd[20295]: No key table entry found for host/localhost@REALM while getting keytab entry for 'host/localhost@REALM'
rpc.gssd[20295]: Success getting keytab entry for nfs/*@REALM
rpc.gssd[20295]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_REALM' are good until 1364700223
rpc.gssd[20295]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_REALM' are good until 1364700223
rpc.gssd[20295]: using FILE:/tmp/krb5cc_machine_REALM as credentials cache for machine creds
rpc.gssd[20295]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_REALM
rpc.gssd[20295]: creating context using fsuid 0 (save_uid 0)
rpc.gssd[20295]: creating tcp client for server server.domain
rpc.gssd[20295]: DEBUG: port already set to 2049
rpc.gssd[20295]: creating context with server nfs@server.domain
rpc.gssd[20295]: DEBUG: serialize_krb5_ctx: lucid version!
rpc.gssd[20295]: prepare_krb5_rfc4121_buffer: protocol 1
rpc.gssd[20295]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32
rpc.gssd[20295]: doing downcall

I'm not sure why does it try to get a key for CLIENT$@REALM (Where's the dollar sign at the end of the client name coming from?)

reish
  • 374
  • 1
  • 4
  • 12
  • check that times are in sync on the client and server – kofemann Mar 31 '13 at 07:58
  • 1
    this is wrong - host/localhost@. It should use names used in ktab files. – kofemann Mar 31 '13 at 07:59
  • Time is synced on both server and the client. – reish Mar 31 '13 at 09:37
  • check that host names do not point to 127.0.0.1 in /etc/hosts. Could you provide the keytab entries list? – kofemann Mar 31 '13 at 11:17
  • @tigran - The hosts resolved to 127.0.0.1 at first, which was my first problem causing the mount to hang. When I fixed that I started to experiment the second problem - permission denied issues. I attached the keytab entries list to the post. – reish Mar 31 '13 at 11:29
  • did you check that rpc.gssd is running on the server? – kofemann Apr 24 '13 at 19:01
  • Should rpc.gssd run on the server and not just on the client? I thought that the server should only run rpc.svcgssd – reish Apr 24 '13 at 20:40
  • you are right, rpc.svcgssd . – kofemann Apr 24 '13 at 21:27
  • svcgssd does run on the server. I must say I really appreciate your attempts to help – reish Apr 26 '13 at 05:35
  • I think I might have the same problem here. Can you please tell me how you have increased the verbosity so that I can verify? – d_inevitable May 12 '13 at 12:29
  • On Gentoo based distributions you can edit `/etc/conf.d/nfs` and append -vv to OPTS_RPC_GSSD and OPTS_RPC_SVCGSSD – reish May 13 '13 at 19:17
  • I can't see in your question if your `/etc/exports` file includes a `fsid=0` or `fsid=root`, does it? – dawud Jul 13 '13 at 09:07
  • You really need the log from the KDC to resolve this. And it looks like your client may also be having an issue with its `/tmp` directory. Since you have said this is no longer reproducible, I'm going to close it. – Michael Hampton Dec 17 '13 at 10:15

0 Answers0