Hide Forgot
Apparently, currently nfs-utils try to construct the principal name for the local host and then hope it is matched in the keytab to get a TGT for operations. It would be less wasteful to instead open the keytab and list the principals found in there, then pick the appropriate name in the right form. This way nfs-utils will be lss prone to failure for misconfgured hosts. As long as the keytab has a key nfs-utils will always be able to find a key to use regardless of what thge machine thinks is the hostname (which sometimes can be wrong due to not infrequen /etc/hosts or other misconfigurations) This would also allow to use native AD principal names for computers (in the form of FOOBAR$@REALM) for machines joined to an AD domain via samba tools, without having to add any explicit configuration for it. If it is found give precedence to the AD form otherwise look for nfs/fqdn form. HTH
(In reply to comment #0) > Apparently, currently nfs-utils try to construct the principal name for the > local host and then hope it is matched in the keytab to get a TGT for > operations. > > It would be less wasteful to instead open the keytab and list the principals > found in there, then pick the appropriate name in the right form. How would it be known what the "right form" is? > > This way nfs-utils will be lss prone to failure for misconfgured hosts. > As long as the keytab has a key nfs-utils will always be able to find a key to > use regardless of what thge machine thinks is the hostname (which sometimes can > be wrong due to not infrequen /etc/hosts or other misconfigurations) > > This would also allow to use native AD principal names for computers (in the > form of FOOBAR$@REALM) for machines joined to an AD domain via samba tools, > without having to add any explicit configuration for it. If it is found give > precedence to the AD form otherwise look for nfs/fqdn form. You are referring to this patch? http://marc.info/?t=129304580900004&r=1&w=2
(In reply to comment #2) > (In reply to comment #0) > > Apparently, currently nfs-utils try to construct the principal name for the > > local host and then hope it is matched in the keytab to get a TGT for > > operations. > > > > It would be less wasteful to instead open the keytab and list the principals > > found in there, then pick the appropriate name in the right form. > How would it be known what the "right form" is? The canonical name for the nfs service is nfs/ Additionally I think host/ and some other may be supported. So the idea would be to search the keytab for those forms in order of precedence. (nfs/ first, then host/, then ...). If native AD computer names support is required then also search for a principal name of the form FOOBAR$@REALM and give that precendence over the other forms. > > This way nfs-utils will be lss prone to failure for misconfgured hosts. > > As long as the keytab has a key nfs-utils will always be able to find a key to > > use regardless of what thge machine thinks is the hostname (which sometimes can > > be wrong due to not infrequen /etc/hosts or other misconfigurations) > > > > This would also allow to use native AD principal names for computers (in the > > form of FOOBAR$@REALM) for machines joined to an AD domain via samba tools, > > without having to add any explicit configuration for it. If it is found give > > precedence to the AD form otherwise look for nfs/fqdn form. > You are referring to this patch? > http://marc.info/?t=129304580900004&r=1&w=2 Yes it looks like it.
Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as an exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
hi Steve, Could you tell me how to test it or is there any easy way to verify it?
(In reply to comment #8) > hi Steve, > Could you tell me how to test it or is there any easy way to verify it? I hate to say this but know I don't. Maybe Simo might
The easiest way would be to get a keytab with the fqdn corresponding to the DNS name assigned to the machine and configure a NFS server with it. Then change the hostanme of the machine so that all other machines still see it with the old name, but the machine itself thinks it has a different name. If the new search method is done correctly you should still be able to properly handle krb5 authentication because the nfs code will not try to build the key to use with nfs/gethostname()@REALM but will instead first search anything that matches nfs/*@REALM and it will find the key nfs/original.fqdn@REALM even if original.fqdn != gethostname() and it will successfully work with it.
(In reply to comment #10) > The easiest way would be to get a keytab with the fqdn corresponding to the DNS > name assigned to the machine and configure a NFS server with it. > Then change the hostanme of the machine so that all other machines still see it > with the old name, but the machine itself thinks it has a different name. > > If the new search method is done correctly you should still be able to properly > handle krb5 authentication because the nfs code will not try to build the key > to use with nfs/gethostname()@REALM but will instead first search anything that > matches nfs/*@REALM and it will find the key nfs/original.fqdn@REALM even if > original.fqdn != gethostname() and it will successfully work with it. hi, Seems there's problem when I test it, pls help to check if caused by my wrong test steps or still code done incorrectly? [root@ibm-ls22-01 ~]# uname -a Linux test.rhts.eng.nay.redhat.com 2.6.32-125.el6.x86_64 #1 SMP Mon Mar 21 10:06:08 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux [root@ibm-ls22-01 ~]# rpm -qa|grep nfs-utils nfs-utils-1.2.3-6.el6.x86_64 nfs-utils-lib-1.1.5-3.el6.x86_64 First, I set up kdc/nfsv4 and mount successfully: [root@ibm-ls22-01 ~]# mount -t nfs4 -o sec=krb5 ibm-ls22-01.rhts.eng.nay.redhat.com:/tmp /mnt [root@ibm-ls22-01 ~]# cat /proc/mounts ... ibm-ls22-01.rhts.eng.nay.redhat.com:/tmp/ /mnt nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=10.66.86.24,minorversion=0,local_lock=none,addr=10.66.86.24 0 0 [root@ibm-ls22-01 ~]# klist -k Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 nfs/ibm-ls22-01.rhts.eng.nay.redhat.com.NAY.REDHAT.COM 2 nfs/ibm-ls22-01.rhts.eng.nay.redhat.com.NAY.REDHAT.COM 2 nfs/ibm-ls22-01.rhts.eng.nay.redhat.com.NAY.REDHAT.COM 2 nfs/ibm-ls22-01.rhts.eng.nay.redhat.com.NAY.REDHAT.COM 2 nfs/ibm-ls22-01.rhts.eng.nay.redhat.com.NAY.REDHAT.COM 2 nfs/ibm-ls22-01.rhts.eng.nay.redhat.com.NAY.REDHAT.COM Then, I change hostname and mount again: [root@ibm-ls22-01 ~]# hostname test.rhts.eng.nay.redhat.com [root@ibm-ls22-01 ~]# hostname test.rhts.eng.nay.redhat.com [root@ibm-ls22-01 ~]# mount -t nfs4 -o sec=krb5 ibm-ls22-01.rhts.eng.nay.redhat.com:/tmp /mnt mount.nfs4: access denied by server while mounting ibm-ls22-01.rhts.eng.nay.redhat.com:/tmp [root@ibm-ls22-01 ~]# rpc.gssd -fvvv beginning poll dir_notify_handler: sig 37 si 0x7fff2fa541b0 data 0x7fff2fa54080 dir_notify_handler: sig 37 si 0x7fff2fa50af0 data 0x7fff2fa509c0 dir_notify_handler: sig 37 si 0x7fff2fa4f7f0 data 0x7fff2fa4f6c0 handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnte) handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnte) process_krb5_upcall: service is '<null>' Full hostname for 'ibm-ls22-01.rhts.eng.nay.redhat.com' is 'ibm-ls22-01.rhts.eng.nay.redhat.com' Name or service not known while getting full hostname for 'test.rhts.eng.nay.redhat.com' ERROR: gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host ibm-ls22-01.rhts.eng.nay.redhat.com ERROR: No credentials found for connection to server ibm-ls22-01.rhts.eng.nay.redhat.com doing error downcall dir_notify_handler: sig 37 si 0x7fff2fa541b0 data 0x7fff2fa54080 dir_notify_handler: sig 37 si 0x7fff2fa541b0 data 0x7fff2fa54080 dir_notify_handler: sig 37 si 0x7fff2fa4fa70 data 0x7fff2fa4f940 dir_notify_handler: sig 37 si 0x7fff2fa4fa70 data 0x7fff2fa4f940 dir_notify_handler: sig 37 si 0x7fff2fa4fa70 data 0x7fff2fa4f940 dir_notify_handler: sig 37 si 0x7fff2fa4fa70 data 0x7fff2fa4f940 dir_notify_handler: sig 37 si 0x7fff2fa4fa70 data 0x7fff2fa4f940 destroying client /var/lib/nfs/rpc_pipefs/nfs/clntf destroying client /var/lib/nfs/rpc_pipefs/nfs/clnte ^Cexiting on signal 2 If restart rpcsvcgssd service and failed also, log shown as below: Apr 8 05:02:00 ibm-ls22-01 rpc.svcgssd[4005]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_BAD_NAME (An invalid name was supplied) - Hostname cannot be canonicalized() Apr 8 05:02:00 ibm-ls22-01 rpc.svcgssd[4005]: unable to obtain root (machine) credentials Apr 8 05:02:00 ibm-ls22-01 rpc.svcgssd[4005]: do you have a keytab entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab?
Is ibm-ls22-01.rhts.eng.nay.redhat.com resolvable on the machine ? Also please use different machines for the client and the server, I don't know if the whole stack properly supports a mismatching name, better to confine which part is wrong by running the client and the server on separate hosts. In any case this test confirms that picking the first available name is not completely working yet and the stack still pretty much rely on your hostname to match the fqdn part of the principal name in the keytab.
I pasted rpc.gssd logs again for two test ways: 1) use different machines for the client and the server, mount successfully from client when change client's hostname: ... process_krb5_upcall: service is '<null>' Full hostname for 'intel-s3e36-01.rhts.eng.nay.redhat.com' is 'intel-s3e36-01.rhts.eng.nay.redhat.com' Full hostname for 'rpmdiff.lab.eng.brq.redhat.com' is 'rpmdiff.lab.eng.brq.redhat.com' No key table entry found for TEST.LAB.ENG.BRQ.REDHAT.COM$@RHTS.ENG.NAY.REDHAT.COM while getting keytab entry for 'TEST.LAB.ENG.BRQ.REDHAT.COM$@RHTS.ENG.NAY.REDHAT.COM' No key table entry found for root/rpmdiff.lab.eng.brq.redhat.com.NAY.REDHAT.COM while getting keytab entry for 'root/rpmdiff.lab.eng.brq.redhat.com.NAY.REDHAT.COM' No key table entry found for nfs/rpmdiff.lab.eng.brq.redhat.com.NAY.REDHAT.COM while getting keytab entry for 'nfs/rpmdiff.lab.eng.brq.redhat.com.NAY.REDHAT.COM' No key table entry found for host/rpmdiff.lab.eng.brq.redhat.com.NAY.REDHAT.COM while getting keytab entry for 'host/rpmdiff.lab.eng.brq.redhat.com.NAY.REDHAT.COM' Success getting keytab entry for nfs/*@RHTS.ENG.NAY.REDHAT.COM Successfully obtained machine credentials for principal 'nfs/intel-s3e36-01.rhts.eng.nay.redhat.com.NAY.REDHAT.COM' stored in ccache 'FILE:/tmp/krb5cc_machine_RHTS.ENG.NAY.REDHAT.COM' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_RHTS.ENG.NAY.REDHAT.COM' are good until 1302710320 using FILE:/tmp/krb5cc_machine_RHTS.ENG.NAY.REDHAT.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_RHTS.ENG.NAY.REDHAT.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server intel-s3e36-01.rhts.eng.nay.redhat.com DEBUG: port already set to 2049 creating context with server nfs.eng.nay.redhat.com 2) use one server(nfs server) and mount from the same server/localhost, then mount failed when change hostname( to testserver.rhts.eng.nay.redhat.com): ... process_krb5_upcall: service is '<null>' Full hostname for 'intel-s3e36-01.rhts.eng.nay.redhat.com' is 'intel-s3e36-01.rhts.eng.nay.redhat.com' Name or service not known while getting full hostname for 'testserver.rhts.eng.nay.redhat.com' ERROR: gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host intel-s3e36-01.rhts.eng.nay.redhat.com ERROR: No credentials found for connection to server intel-s3e36-01.rhts.eng.nay.redhat.com doing error downcall dir_notify_handler: sig 37 si 0xbff3a6ac data 0xbff3a72c note: the keytab include nfs principal and is available before change hostname. Others all are fine and work, I just change hostname, then umount and mount again.
Although it is nice to see that the client can cope, what really matters here is whether the server copes with having hostname that differs from the principal name stored in the server's keytab. So until test 2 passes it looks like the work is incomplete unfortunately. Also please when you change the server hostname try mounting from a separate properly configured client, so we have only server side defects showing up in the server.
(In reply to comment #19) > Although it is nice to see that the client can cope, what really matters here > is whether the server copes with having hostname that differs from the > principal name stored in the server's keytab. > > So until test 2 passes it looks like the work is incomplete unfortunately. > > Also please when you change the server hostname try mounting from a separate > properly configured client, so we have only server side defects showing up in > the server. yes, I confirmed mount from a separate client is ok after changing server hostname. [root@hp-dl385g7-02 ~]# klist -c /tmp/krb5cc_machine_RHTS.ENG.NAY.REDHAT.COM Ticket cache: FILE:/tmp/krb5cc_machine_RHTS.ENG.NAY.REDHAT.COM Default principal: nfs/hp-dl385g7-02.lab.eng.brq.redhat.com.NAY.REDHAT.COM Valid starting Expires Service principal 04/13/11 07:03:53 04/14/11 07:03:53 krbtgt/RHTS.ENG.NAY.REDHAT.COM.NAY.REDHAT.COM renew until 04/13/11 07:03:53 04/13/11 07:03:54 04/14/11 07:03:53 nfs/intel-s3e36-01.rhts.eng.nay.redhat.com.NAY.REDHAT.COM renew until 04/13/11 07:03:53 [root@hp-dl385g7-02 ~]# cat /proc/mounts ... intel-s3e36-01.rhts.eng.nay.redhat.com:/tmp/ /mnt nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5,clientaddr=10.34.35.100,minorversion=0,local_lock=none,addr=10.66.86.26 0 0 rpc.gssd log: ... Full hostname for 'intel-s3e36-01.rhts.eng.nay.redhat.com' is 'intel-s3e36-01.rhts.eng.nay.redhat.com' Full hostname for 'hp-dl385g7-02.lab.eng.brq.redhat.com' is 'hp-dl385g7-02.lab.eng.brq.redhat.com' No key table entry found for HP-DL385G7-02.LAB.ENG.BRQ.REDHAT.COM$@RHTS.ENG.NAY.REDHAT.COM while getting keytab entry for 'HP-DL385G7-02.LAB.ENG.BRQ.REDHAT.COM$@RHTS.ENG.NAY.REDHAT.COM' No key table entry found for root/hp-dl385g7-02.lab.eng.brq.redhat.com.NAY.REDHAT.COM while getting keytab entry for 'root/hp-dl385g7-02.lab.eng.brq.redhat.com.NAY.REDHAT.COM' Success getting keytab entry for 'nfs/hp-dl385g7-02.lab.eng.brq.redhat.com.NAY.REDHAT.COM' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_RHTS.ENG.NAY.REDHAT.COM' are good until 1302779033 INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_RHTS.ENG.NAY.REDHAT.COM' are good until 1302779033 using FILE:/tmp/krb5cc_machine_RHTS.ENG.NAY.REDHAT.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_RHTS.ENG.NAY.REDHAT.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server intel-s3e36-01.rhts.eng.nay.redhat.com DEBUG: port already set to 2049 creating context with server nfs.eng.nay.redhat.com ... and mount from server failed like above comments. Seems there's issue on server side, so I change the bug status to Assigned in order to let developer to check. If need any extra testing pls let me know, thank.
So if I'm understanding correct, when two different machine are used the mount works but when only one machine is used (aka loopback mount) the mount fails?
I've been following along and have been a bit confused about the perceived problem. The original problem statement generalized nfs-utils. The process for finding a keytab entry is different for rpc.gssd (client side) and rpc.svcgssd (server side). I believe you've verified that the client side (rpc.gssd) will use whatever suitable keytab it can find? That was the result of a lot of work. According to the RFC, the server *must* use a key in the form 'nfs/<hostname>@<REALM>'. However, for cluster or hot-swap environments the <hostname> part may not match the machine's real hostname. For that case there is the "-n" option, which says don't acquire credentials at startup, but try to find a keytab which matches the name in the client's request. If you are running rpc.svcgssd without the "-n" option and change the host's name, you must restart rpc.svcgssd so it uses the new hostname when acquiring credentials. I haven't seen anything here to make me think there is a bug in either the client or server side. Perhaps I'm still missing something?
Kevin, it is not necessarily a bug, it is a matter of desired behaviour. Although the rfc says the server must use the nfs/fqdn@REALM form, the server can certainly avoid to try to reconstruct the principal name based on what it knows, and instead just try to match the first key of that form that "works". This allows you to be more resilient when it comes to the server view of the world, and keep working as long as the client has a ticket that the server can actually decrypt, regardless of the name the client actually used, or the name the server believes it has. This is especially handy when you have "broken" setups where the server is set up with the gethostname() returning just the short non fully qualified name, or some component "smartly" assigning a hostname as provided by dhcp that doesn't match the keytab that was originally provided to the server. Of course the client needs to be able to resolve server fqdn (as present in the principal name) to the ip address of the server. The example comes down to something as simple as the following: - On the server, the keytab has a key for nfs/server.example.com - The server is configured so that gethostname() returns just "server". (or maybe: dhcp-1-2-3-4.example.com) - The client tries to mount from "server.example.com" and has a valid ticket for it because server.example.com resolves to the correct server's ip address Now if the server insist on trying to find a key named nfs/server (or nfs/dhcp-1-2-3-4.example.com) it will fail to accept a connection from a client that otherwise has a perfectly valid ticket and should just work. I hope this explains the cases where letting gssapi pick the first good key is useful rather than trying to force it to try with a specific principal name. Further interop reasons follow: When the nfs server machine is joined to the windows world, it may have a keytab with a key of the form SERVER$@EXAMPLE.COM, and although this key isn't strictly of the form nfs/fqdn@REALM, the KDC will happily release the client a ticket for nfs/server.example.com because in the windows world principal aliases are used quite a lot and the host key is alias to a great nuber of other principal names. So if the server isn't picky and allows for using whatever key actually "works" instead of trying to force a specific name, it means it will make integration with winbind and windows domains *much* simpler, as the server will be able to use the key named SERVER$@EXAMPLE.COM even if the client got a ticket for nfs/server.example.com (it will work because the encryption keys are the same for all these principal names). SSS
Hi Simo, The "-n" option should handle the cases described before, "Further interop reasons follow:". I am not sure there is a reasonable way to handle the case where the server has a keytab entry for "SERVER$@EXAMPLE.COM" and the client thinks it is talking to "nfs/server.example.com". I know that the result of "-n" basically tells Kerberos to try and match a key to whatever name the client used. I don't know if there is a way to indicate that it (the Kerberos library) should actually try each key in the keytab regardless of the name the client supplied. (There is a security consideration there.) K.C.
(In reply to comment #24) > Hi Simo, > The "-n" option should handle the cases described before, "Further interop > reasons follow:". > > I am not sure there is a reasonable way to handle the case where the server has > a keytab entry for "SERVER$@EXAMPLE.COM" and the client thinks it is talking to > "nfs/server.example.com". I know that the result of "-n" basically > tells Kerberos to try and match a key to whatever name the client used. I > don't know if there is a way to indicate that it (the Kerberos library) should > actually try each key in the keytab regardless of the name the client supplied. > (There is a security consideration there.) By not specifying a name the kerberos library will try them all, but this may happen only in recent libraries. I can check the details for MIT Kerberos libraries if you want. Can you explicit what security considerations do you have in mind ? Simo.
(In reply to comment #22) > I've been following along and have been a bit confused about the perceived > problem. The original problem statement generalized nfs-utils. The process > for finding a keytab entry is different for rpc.gssd (client side) and > rpc.svcgssd (server side). > > I believe you've verified that the client side (rpc.gssd) will use whatever > suitable keytab it can find? That was the result of a lot of work. > > According to the RFC, the server *must* use a key in the form > 'nfs/<hostname>@<REALM>'. However, for cluster or hot-swap environments the > <hostname> part may not match the machine's real hostname. For that case there > is the "-n" option, which says don't acquire credentials at startup, but try to > find a keytab which matches the name in the client's request. > > If you are running rpc.svcgssd without the "-n" option and change the host's > name, you must restart rpc.svcgssd so it uses the new hostname when acquiring > credentials. > > I haven't seen anything here to make me think there is a bug in either the > client or server side. Perhaps I'm still missing something? hi, I haven't seen the "-n" option for rpc.svcgssd [root@intel-s3e36-01 ~]# rpm -qa|grep nfs-utils nfs-utils-1.2.3-6.el6.i686 nfs-utils-lib-1.1.5-3.el6.i686 rpc.svcgssd(8) rpc.svcgssd(8) NAME rpc.svcgssd - server-side rpcsec_gss daemon SYNOPSIS rpc.svcgssd [-v] [-r] [-i] [-f] [-p principal] and if I restart rpc.svcgssd after change server's hostname, the service will fail to start, the log shown as below: Apr 13 22:52:53 intel-s3e36-01 rpc.svcgssd[15335]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_BAD_NAME (An invalid name was supplied) - Hostname cannot be canonicalized((null)) Apr 13 22:52:53 intel-s3e36-01 rpc.svcgssd[15335]: unable to obtain root (machine) credentials Apr 13 22:52:53 intel-s3e36-01 rpc.svcgssd[15335]: do you have a keytab entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab?
(In reply to comment #21) > So if I'm understanding correct, when two different machine are used > the mount works but when only one machine is used (aka loopback > mount) the mount fails? seem yes. If I start rpc.gssd and mount from a separate client that is ok when change nfs server's hostname. If I start rpc.gssd on the nfs server and mount from itself, mount will fail when change its hostname. You could check the server if you need: intel-s3e36-01.rhts.eng.nay.redhat.com/10.66.86.26, root/redhat
(In reply to comment #25) > (In reply to comment #24) > > Hi Simo, > > The "-n" option should handle the cases described before, "Further interop > > reasons follow:". > > > > I am not sure there is a reasonable way to handle the case where the server has > > a keytab entry for "SERVER$@EXAMPLE.COM" and the client thinks it is talking to > > "nfs/server.example.com". I know that the result of "-n" basically > > tells Kerberos to try and match a key to whatever name the client used. I > > don't know if there is a way to indicate that it (the Kerberos library) should > > actually try each key in the keytab regardless of the name the client supplied. > > (There is a security consideration there.) > > By not specifying a name the kerberos library will try them all, but > this may happen only in recent libraries. I can check the details for > MIT Kerberos libraries if you want. > > Can you explicit what security considerations do you have in mind ? > > Simo. Recent versions of the Kerberos libraries may by different, but my understanding was that there must be a keytab entry with a name matching the name supplied by the client. Otherwise, the client cannot be sure it is talking to the server it thought it was talking to. K.C.
(In reply to comment #29) > Recent versions of the Kerberos libraries may by different, but my > understanding was that there must be a keytab entry with a name matching the > name supplied by the client. That's the usual case but it is not strictly necessary. > Otherwise, the client cannot be sure it is > talking to the server it thought it was talking to. The client is sure because the server can reply at all. The ticket the client sends to the server is encrypted with the servers long term key, which is known only to the server and the KDC that released the ticket to the client. If the server can reply it is proof it was able to decrypt the ticket and obtain the session key used to talk back to the client. Whatever name the key is labelled with, is not really important. Simo.
(In reply to comment #27) > (In reply to comment #22) > > I've been following along and have been a bit confused about the perceived > > problem. The original problem statement generalized nfs-utils. The process > > for finding a keytab entry is different for rpc.gssd (client side) and > > rpc.svcgssd (server side). > > > > I believe you've verified that the client side (rpc.gssd) will use whatever > > suitable keytab it can find? That was the result of a lot of work. > > > > According to the RFC, the server *must* use a key in the form > > 'nfs/<hostname>@<REALM>'. However, for cluster or hot-swap environments the > > <hostname> part may not match the machine's real hostname. For that case there > > is the "-n" option, which says don't acquire credentials at startup, but try to > > find a keytab which matches the name in the client's request. > > > > If you are running rpc.svcgssd without the "-n" option and change the host's > > name, you must restart rpc.svcgssd so it uses the new hostname when acquiring > > credentials. > > > > I haven't seen anything here to make me think there is a bug in either the > > client or server side. Perhaps I'm still missing something? > > hi, > I haven't seen the "-n" option for rpc.svcgssd > [root@intel-s3e36-01 ~]# rpm -qa|grep nfs-utils > nfs-utils-1.2.3-6.el6.i686 > nfs-utils-lib-1.1.5-3.el6.i686 > > rpc.svcgssd(8) rpc.svcgssd(8) > > NAME > rpc.svcgssd - server-side rpcsec_gss daemon > > SYNOPSIS > rpc.svcgssd [-v] [-r] [-i] [-f] [-p principal] The -n option has been there since nfs-utils-1.1.0 (maybe forever???). Is there possibly a Redhat patch removing it?
(In reply to comment #36) > > hi, > > I haven't seen the "-n" option for rpc.svcgssd > > [root@intel-s3e36-01 ~]# rpm -qa|grep nfs-utils > > nfs-utils-1.2.3-6.el6.i686 > > nfs-utils-lib-1.1.5-3.el6.i686 > > > > rpc.svcgssd(8) rpc.svcgssd(8) > > > > NAME > > rpc.svcgssd - server-side rpcsec_gss daemon > > > > SYNOPSIS > > rpc.svcgssd [-v] [-r] [-i] [-f] [-p principal] > > The -n option has been there since nfs-utils-1.1.0 (maybe forever???). Is > there possibly a Redhat patch removing it? The -n option is there, its just not in the man page... Note the usage: rpc.svcgssd [-n] [-f] [-v] [-r] [-i] [-p principal]
(In reply to comment #38) > (In reply to comment #36) > > > hi, > > > I haven't seen the "-n" option for rpc.svcgssd > > > [root@intel-s3e36-01 ~]# rpm -qa|grep nfs-utils > > > nfs-utils-1.2.3-6.el6.i686 > > > nfs-utils-lib-1.1.5-3.el6.i686 > > > > > > rpc.svcgssd(8) rpc.svcgssd(8) > > > > > > NAME > > > rpc.svcgssd - server-side rpcsec_gss daemon > > > > > > SYNOPSIS > > > rpc.svcgssd [-v] [-r] [-i] [-f] [-p principal] > > > > The -n option has been there since nfs-utils-1.1.0 (maybe forever???). Is > > there possibly a Redhat patch removing it? > The -n option is there, its just not in the man page... > Note the usage: rpc.svcgssd [-n] [-f] [-v] [-r] [-i] [-p principal] Now, *that's* a bug!! ;-)
verified against above comments, and file separate bug 697356 against server side issue and file the -n option issue - bug 697359.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Prior to this update, nfs-utils tried to construct the principal name for the local host and attempted to match it against entries in the keytab file to acquire a Ticket Granting Ticket (TGT). With this update, nfs-utils opens the file and picks the appropriate name from the list of principals so that the NFS client machine is able to authenticate even after its host name is changed.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0738.html
*** Bug 697356 has been marked as a duplicate of this bug. ***
*** Bug 743288 has been marked as a duplicate of this bug. ***