Bug#622146: This is broken for me.
On Sun, Oct 23, 2011 at 05:16:59PM -0400, Daniel Kahn Gillmor wrote: On 10/23/2011 02:25 PM, Rob Naccarato wrote: On 11-10-23 01:18 PM, Sam Hartman wrote: Rob == Rob Naccarator...@naccy.org writes: Rob This doesn't appear to be fixed to me. I get the same Rob problems. I have even installed backported kernel Rob (2.6.39-bpo.2-amd64) and nfs-utils (1:1.2.4-1~bpo60+1) and I Rob still get these: This requires fixes in krb5 and nfs-utils. krb5 has been fixed, but nothing gets better until the nfs-utils fix. So, nfs-utils 1.2.5, then? When's that suppose to be available? I imagine this is a pretty critical issue for people. It is for me, at least. I'm the current backporter of nfs-utils. I use 1:1.2.4-1~bpo60+1 with the squeeze-backports kernel (nfs server and nfs clients both use these versions) and a squeeze kdc configured with: supported_enctypes = aes128-cts:normal I'm able to use kerberized (sec=krb5p) nfsv4 mounts in this arrangement. Could you clarify how your configuration differs from what i've described above so i could be sure what might need changing? Ok, here we go. supported_enctypes = aes256-cts:normal arcfour-hmac:normal \ des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm \ des:onlyrealm des:afs3 aes128-cts:normal Client (khan) attempting to use sec=krb5. root@khan:/# klist -e -k /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal -- 2 host/khan.some.domain...@naccy.org (AES-256 CTS mode with 96-bit SHA-1 HMAC) 2 host/khan.some.domain...@naccy.org (ArcFour with HMAC/md5) 2 host/khan.some.domain...@naccy.org (Triple DES cbc mode with HMAC/sha1) 2 host/khan.some.domain...@naccy.org (DES cbc mode with CRC-32) 2 nfs/khan.some.domain...@naccy.org (AES-256 CTS mode with 96-bit SHA-1 HMAC) 2 nfs/khan.some.domain...@naccy.org (ArcFour with HMAC/md5) 2 nfs/khan.some.domain...@naccy.org (Triple DES cbc mode with HMAC/sha1) 2 nfs/khan.some.domain...@naccy.org (DES cbc mode with CRC-32) /etc/fstab: blackdog:/ /shares nfs4_netdev,auto,sec=krb5,acl 0 0 Server (blackdog), with kdc, exporting nfs4, when I attempt to mount the above: Oct 24 09:32:36 blackdog rpc.svcgssd[22979]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Encryption type not permitted Both machines, client and server have: linux-image-2.6.39-bpo.2-amd64 nfs-kernel-server 1:1.2.4-1~bpo60+1 Both machines, client and server have in krb5.conf: allow_weak_crypto = true Thanks. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111024134233.ga22...@naccy.org
Bug#622146: This is broken for me.
On 10/24/2011 09:42 AM, Rob Naccarato wrote: supported_enctypes = aes256-cts:normal arcfour-hmac:normal \ des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm \ des:onlyrealm des:afs3 aes128-cts:normal Client (khan) attempting to use sec=krb5. root@khan:/# klist -e -k /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal -- 2 host/khan.some.domain...@naccy.org (AES-256 CTS mode with 96-bit SHA-1 HMAC) 2 host/khan.some.domain...@naccy.org (ArcFour with HMAC/md5) 2 host/khan.some.domain...@naccy.org (Triple DES cbc mode with HMAC/sha1) 2 host/khan.some.domain...@naccy.org (DES cbc mode with CRC-32) 2 nfs/khan.some.domain...@naccy.org (AES-256 CTS mode with 96-bit SHA-1 HMAC) 2 nfs/khan.some.domain...@naccy.org (ArcFour with HMAC/md5) 2 nfs/khan.some.domain...@naccy.org (Triple DES cbc mode with HMAC/sha1) 2 nfs/khan.some.domain...@naccy.org (DES cbc mode with CRC-32) this appears to have everything *but* aes128-cts:normal, fwiw. My example client has: 0 example:~# klist -e -k /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal -- 2 host/example.example@example.org (AES-128 CTS mode with 96-bit SHA-1 HMAC) 0 example:~# /etc/fstab: blackdog:/ /shares nfs4_netdev,auto,sec=krb5,acl 0 0 0 example:~# grep nfs /etc/fstab nfshost:/ /usr/local/data nfs4 sec=krb5p,fsc 0 0 0 example:~# i don't think the fsc is relevant to this discussion -- and i can't imagine that the difference between krb5 and krb5p is the issue. Server (blackdog), with kdc, exporting nfs4, when I attempt to mount the above: Oct 24 09:32:36 blackdog rpc.svcgssd[22979]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Encryption type not permitted can you show the same klist on blackdog? here's what i've got on my server: 0 nfshost:~# klist -e -k /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal -- 8 nfs/nfshost.example@example.org (AES-128 CTS mode with 96-bit SHA-1 HMAC) 0 nfshost:~# Both machines, client and server have: linux-image-2.6.39-bpo.2-amd64 nfs-kernel-server 1:1.2.4-1~bpo60+1 you shouldn't need nfs-kernel-server on the client -- what version of nfs-common do you have on the client? Both machines, client and server have in krb5.conf: allow_weak_crypto = true A useful test might be to *reduce* the number of supported_enctypes to a select one or two, then change the keys for the client and the server (and for any user account using krb5 authentication) and re-try. hth, --dkg signature.asc Description: OpenPGP digital signature
Bug#622146: This is broken for me.
On Mon, Oct 24, 2011 at 12:00:17PM -0400, Daniel Kahn Gillmor wrote: On 10/24/2011 09:42 AM, Rob Naccarato wrote: supported_enctypes = aes256-cts:normal arcfour-hmac:normal \ des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm \ des:onlyrealm des:afs3 aes128-cts:normal Client (khan) attempting to use sec=krb5. root@khan:/# klist -e -k /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal -- 2 host/khan.some.domain...@naccy.org (AES-256 CTS mode with 96-bit SHA-1 HMAC) 2 host/khan.some.domain...@naccy.org (ArcFour with HMAC/md5) 2 host/khan.some.domain...@naccy.org (Triple DES cbc mode with HMAC/sha1) 2 host/khan.some.domain...@naccy.org (DES cbc mode with CRC-32) 2 nfs/khan.some.domain...@naccy.org (AES-256 CTS mode with 96-bit SHA-1 HMAC) 2 nfs/khan.some.domain...@naccy.org (ArcFour with HMAC/md5) 2 nfs/khan.some.domain...@naccy.org (Triple DES cbc mode with HMAC/sha1) 2 nfs/khan.some.domain...@naccy.org (DES cbc mode with CRC-32) this appears to have everything *but* aes128-cts:normal, fwiw. My example client has: 0 example:~# klist -e -k /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal -- 2 host/example.example@example.org (AES-128 CTS mode with 96-bit SHA-1 HMAC) 0 example:~# Fair enough, I now have this on the client: root@khan:/etc# klist -e -k /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal -- 4 nfs/khan.some.domain...@naccy.org (AES-128 CTS mode with 96-bit SHA-1 HMAC) 4 host/khan.some.domain...@naccy.org (AES-128 CTS mode with 96-bit SHA-1 HMAC) I also have this on the server: blackdog:/etc# klist -e -k /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal -- 8 host/blackdog.some.domain...@naccy.org (AES-128 CTS mode with 96-bit SHA-1 HMAC) 7 nfs/blackdog.some.domain...@naccy.org (AES-128 CTS mode with 96-bit SHA-1 HMAC) /etc/fstab: blackdog:/ /shares nfs4_netdev,auto,sec=krb5,acl 0 0 0 example:~# grep nfs /etc/fstab nfshost:/ /usr/local/data nfs4 sec=krb5p,fsc 0 0 0 example:~# i don't think the fsc is relevant to this discussion -- and i can't imagine that the difference between krb5 and krb5p is the issue. Yep, and I have no need for the encryption across the wire, either. Server (blackdog), with kdc, exporting nfs4, when I attempt to mount the above: Oct 24 09:32:36 blackdog rpc.svcgssd[22979]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Encryption type not permitted can you show the same klist on blackdog? here's what i've got on my server: 0 nfshost:~# klist -e -k /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal -- 8 nfs/nfshost.example@example.org (AES-128 CTS mode with 96-bit SHA-1 HMAC) 0 nfshost:~# Yup, shown above. Both machines, client and server have: linux-image-2.6.39-bpo.2-amd64 nfs-kernel-server 1:1.2.4-1~bpo60+1 you shouldn't need nfs-kernel-server on the client -- what version of nfs-common do you have on the client? nfs-common 1:1.2.4-1~bpo60+1 Both machines, client and server have in krb5.conf: allow_weak_crypto = true A useful test might be to *reduce* the number of supported_enctypes to a select one or two, then change the keys for the client and the server (and for any user account using krb5 authentication) and re-try. So, reduce the list to, say, just aes128-cts:normal? Should I also remove the allow_weak_crypto option? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111024190947.ga26...@naccy.org
Bug#622146: This is broken for me.
On 10/24/2011 03:09 PM, Rob Naccarato wrote: Fair enough, I now have this on the client: root@khan:/etc# klist -e -k /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal -- 4 nfs/khan.some.domain...@naccy.org (AES-128 CTS mode with 96-bit SHA-1 HMAC) 4 host/khan.some.domain...@naccy.org (AES-128 CTS mode with 96-bit SHA-1 HMAC) this looks reasonable to me (funnily, i also have a machine named khan!) I also have this on the server: blackdog:/etc# klist -e -k /etc/krb5.keytab Keytab name: WRFILE:/etc/krb5.keytab KVNO Principal -- 8 host/blackdog.some.domain...@naccy.org (AES-128 CTS mode with 96-bit SHA-1 HMAC) 7 nfs/blackdog.some.domain...@naccy.org (AES-128 CTS mode with 96-bit SHA-1 HMAC) this also looks reasonable to me (there's no need for the kvno to match between the credentials for the two different principals) you shouldn't need nfs-kernel-server on the client -- what version of nfs-common do you have on the client? nfs-common 1:1.2.4-1~bpo60+1 ok, that matches my setup. A useful test might be to *reduce* the number of supported_enctypes to a select one or two, then change the keys for the client and the server (and for any user account using krb5 authentication) and re-try. So, reduce the list to, say, just aes128-cts:normal? Should I also remove the allow_weak_crypto option? yes, that's what i would try -- it appears to be currently working for me. Perhaps someone more experienced with krb5 and nfs than i am can also weigh in with suggestions. Regards, --dkg signature.asc Description: OpenPGP digital signature
Bug#622146: This is broken for me.
On Mon, Oct 24, 2011 at 04:26:10PM -0400, Daniel Kahn Gillmor wrote: On 10/24/2011 03:09 PM, Rob Naccarato wrote: nfs-common 1:1.2.4-1~bpo60+1 ok, that matches my setup. A useful test might be to *reduce* the number of supported_enctypes to a select one or two, then change the keys for the client and the server (and for any user account using krb5 authentication) and re-try. So, reduce the list to, say, just aes128-cts:normal? Should I also remove the allow_weak_crypto option? yes, that's what i would try -- it appears to be currently working for me. Perhaps someone more experienced with krb5 and nfs than i am can also weigh in with suggestions. Alright, my kdc.conf contains: supported_enctypes = aes128-cts:normal Both client and server krb5.conf's have allow_weak_crypto commented out. Now I get a different error on the nfs server: Oct 24 17:39:57 blackdog rpc.svcgssd[28694]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - No supported encryption types (config file error?) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111024214303.ga28...@naccy.org
Bug#622146: This is broken for me.
Rob == Rob Naccarato r...@naccy.org writes: Rob This doesn't appear to be fixed to me. I get the same Rob problems. I have even installed backported kernel Rob (2.6.39-bpo.2-amd64) and nfs-utils (1:1.2.4-1~bpo60+1) and I Rob still get these: This requires fixes in krb5 and nfs-utils. krb5 has been fixed, but nothing gets better until the nfs-utils fix. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/tslobx7iq3f@mit.edu
Bug#622146: This is broken for me.
On 11-10-23 01:18 PM, Sam Hartman wrote: Rob == Rob Naccarator...@naccy.org writes: Rob This doesn't appear to be fixed to me. I get the same Rob problems. I have even installed backported kernel Rob (2.6.39-bpo.2-amd64) and nfs-utils (1:1.2.4-1~bpo60+1) and I Rob still get these: This requires fixes in krb5 and nfs-utils. krb5 has been fixed, but nothing gets better until the nfs-utils fix. So, nfs-utils 1.2.5, then? When's that suppose to be available? I imagine this is a pretty critical issue for people. It is for me, at least. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ea45c0c.8000...@naccy.org
Bug#622146: This is broken for me.
On 10/23/2011 02:25 PM, Rob Naccarato wrote: On 11-10-23 01:18 PM, Sam Hartman wrote: Rob == Rob Naccarator...@naccy.org writes: Rob This doesn't appear to be fixed to me. I get the same Rob problems. I have even installed backported kernel Rob (2.6.39-bpo.2-amd64) and nfs-utils (1:1.2.4-1~bpo60+1) and I Rob still get these: This requires fixes in krb5 and nfs-utils. krb5 has been fixed, but nothing gets better until the nfs-utils fix. So, nfs-utils 1.2.5, then? When's that suppose to be available? I imagine this is a pretty critical issue for people. It is for me, at least. I'm the current backporter of nfs-utils. I use 1:1.2.4-1~bpo60+1 with the squeeze-backports kernel (nfs server and nfs clients both use these versions) and a squeeze kdc configured with: supported_enctypes = aes128-cts:normal I'm able to use kerberized (sec=krb5p) nfsv4 mounts in this arrangement. Could you clarify how your configuration differs from what i've described above so i could be sure what might need changing? Regards, --dkg signature.asc Description: OpenPGP digital signature
Bug#622146: This is broken for me.
This doesn't appear to be fixed to me. I get the same problems. I have even installed backported kernel (2.6.39-bpo.2-amd64) and nfs-utils (1:1.2.4-1~bpo60+1) and I still get these: Oct 22 20:24:54 blackdog rpc.svcgssd[8502]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Encryption type not permitted I have turned off and on allow_weak_crypto in both clients and servers and I'm at a complete loss as to what to do now. Can someone advise? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ea36590.3030...@naccy.org
