Re: the change to krb5.conf, yes I think you need to restart svcgssd. And yes, it does have global effect (limiting all Kerberos connections on the machine to DES), which is not optimal. Offhand, I'm not aware of any changes to gssd or svcgssd between nfs-utils 1.2.2 and 1.2.3 that would affect this. Moving from Kerberos 1.6 to something later would bring in the acceptor subkey issue. (I believe both sides need to have krb5-1.7 or later libraries for the subkey to be used.) But again, your server's kernel _should_ have RPC GSS support for AES. The patch here, http://www.spinics.net/lists/linux-nfs/msg19999.html, along with the Kerberos patch referenced there, should limit the negotiation to DES. (w/o the kernel patch, it will use a default list of only DES enctypes). However, it might be better to figure out why your kernel doesn't like the AES key. Looking back at the other issues like this, the error returned when the kernel doesn't have RPC GSS support for AES was "function not implemented", not "invalid argument". Just as a sanity check, you've verified that the rpcsec_gss_krb5 kernel module is loaded? K.C. On Fri, Mar 18, 2011 at 9:52 AM, Vladimir Elisseev <vovan@xxxxxxxx> wrote: > Kevin, > > Sorry, I have to mention this initially: the server has nfs-utils 1.2.3, but > clients have 1.2.2 (we've tested and upgraded servers firstly without having > any problems). As for the rest, see my comment in-line below. > > Regards, > Vladimir. > > Quoting Kevin Coffman <kwc@xxxxxxxxxxxxxx>: > >> Vladimir, >> Having the raw crypto enabled in the kernel is only part of it. The >> RPC GSS support to make use of it went into 2.6.35, so your server's >> kernel should have that. > > Thanks for clarifying this. > >> >> Did the output from svcgssd change when you added the >> default_tgs_enctypes? Specifically, "prepare_krb5_rfc4121_buffer: >> serializing key with enctype 18 and size 32" should have changed to a >> different enctype and size. > > After changing krb5.conf I saw the same entry "repare_krb5_rfc4121_buffer: > serializing key with enctype 18 and size 32" in the log file. However, I > think I had to restart rpc.svcgssd (is this true?), but I didn't. > Unfortunately, changing default_tgs_enctypes for Kerberos will have global > effect and can be used only for testing purposes. > >> >> If adding default_tgs_enctypes didn't help, the patches dealing with >> "acceptor subkey" won't help. >> >> Does the server continue to work for other clients? > > As I mentioned at the beginning of this mail, clients with nfs-utils 1.2.2 > work just fine and are able use des encryption: > klist -ce /tmp/krb5cc_machine_X.X > Ticket cache: FILE:/tmp/krb5cc_machine_X.X > Default principal: host/x.x.x@xxx > > Valid starting Expires Service principal > 03/18/11 06:40:36 03/19/11 06:40:36 krbtgt/X.X@xxx > Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 > 03/18/11 06:40:37 03/19/11 06:40:36 nfs/nfs.x.x@xxx > Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96 > > >> >> K.C. >> >> On Fri, Mar 18, 2011 at 1:43 AM, Vladimir Elisseev <vovan@xxxxxxxx> wrote: >>> >>> Kevin, >>> >>> I think the kernel configuration on server include AES encryption: >>> zcat /proc/config.gz| grep -i aes >>> CONFIG_CRYPTO_AES=y >>> CONFIG_CRYPTO_AES_X86_64=y >>> # CONFIG_CRYPTO_AES_NI_INTEL is not set >>> IMO, this is sufficient. As for the kerberos version on the client it's >>> 1.9 with patches: CVE-2010-4022, CVE-2011-0281,0282,0283,0284. >>> Changing server's krb5.conf with default_tgs_enctypes = des-cbc-crc >>> doesn't solve this problem. >>> As you suggested I'm going to check patches regarding "acceptor subkey". >>> >>> Regards, >>> Vladimir. >>> >>> On Thu, 2011-03-17 at 18:13 -0400, Kevin Coffman wrote: >>>> >>>> On Thu, Mar 17, 2011 at 2:48 PM, Vladimir Elisseev <vovan@xxxxxxxx> >>>> wrote: >>>> > Hello, >>>> > >>>> > I've got a problem after updating NFS client. I've been trying to find >>>> > possible solution without a success for a while, so I'd appreciate any >>>> > help. All the info is below. Client has kernel 2.6.37 and server >>>> > 2.6.36. >>>> > >>>> > Regards, >>>> > Vladimir. >>>> > >>>> > On the server side the error is "rpc.svcgssd[15159]: qword_eol: fflush >>>> > failed: errno 22 (Invalid argument)", the full track is below: >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: leaving poll >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: handling null request >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: sname = host/x.x.x@xxx >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: nfs4_gss_princ_to_ids: >>>> > calling >>>> > umich_ldap->princ_to_ids >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: ldap_init_and_bind: version >>>> > mismatch between API information and protocol version. Setting >>>> > protocol >>>> > version to 3 >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: nfs4_gss_princ_to_ids: >>>> > umich_ldap->princ_to_ids returned -2 >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: nfs4_gss_princ_to_ids: >>>> > calling >>>> > nsswitch->princ_to_ids >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: nss_getpwnam: name >>>> > 'host/x.x.x@xxx' domain '(null)': resulting localname >>>> > 'host/user.net.home' >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: nfs4_gss_princ_to_ids: >>>> > nsswitch->princ_to_ids returned -2 >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: nfs4_gss_princ_to_ids: final >>>> > return value is -2 >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: DEBUG: serialize_krb5_ctx: >>>> > lucid version! >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: prepare_krb5_rfc4121_buffer: >>>> > protocol 1 >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: prepare_krb5_rfc4121_buffer: >>>> > serializing key with enctype 18 and size 32 >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: doing downcall >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: mech: krb5, hndl len: 4, ctx >>>> > len 52, timeout: 1300464362 (86399 from now), clnt: host@xxxxx, uid: >>>> > -1, >>>> > gid: -1, num aux grps: 0: >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: qword_eol: fflush failed: >>>> > errno >>>> > 22 (Invalid argument) >>>> > Mar 17 17:06:03 srv2 rpc.svcgssd[15159]: WARNING: error writing to >>>> > downcall channel /proc/net/rpc/auth.rpcsec.context/channel: Invalid >>>> > argument >>>> >>>> I've seen this when the negotiated enctype is AES (18), and the kernel >>>> does not have AES support. However, 2.6.36 should have AES support. >>>> Did the client update include a Kerberos version update as well? (See >>>> recently submitted patches regarding "acceptor subkey".) >>>> >>>> The immediate work-around for the acceptor subkey problem is to set >>>> >>>> default_tgs_enctypes = des-cbc-crc >>>> >>>> in the server's /etc/krb5.conf file. Could you try this and see if it >>>> helps? >>>> >>>> K.C. >>>> -- >>>> 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 >>> >>> >> > > > > > -- 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
