Transferring NFSv4 nfs/ keys from KDC to client?

Wendy Lin wendlin1974 at gmail.com
Wed Mar 19 18:16:50 EDT 2014 

On 19 March 2014 14:11, steve <steve at steve-ss.com> wrote:
> On Wed, 2014-03-19 at 13:32 +0100, Wendy Lin wrote:
>> On 19 March 2014 09:55, steve <steve at steve-ss.com> wrote:
>> > On Wed, 2014-03-19 at 00:09 +0100, Wendy Lin wrote:
>> >> On 18 March 2014 23:54, steve <steve at steve-ss.com> wrote:
>> >> > On Tue, 2014-03-18 at 23:20 +0100, Wendy Lin wrote:
>> >> >> Asking here to make sure I got the mechanism right:
>> >> >>
>> >> >> I created the principal nfs/china.mytest.org at TEST1.MYTEST.ORG on the
>> >> >> KDC machine so that NFSv4 client china.mytest.org can mount a NFSv4
>> >> >> filesystem.
>> >> >>
>> >> >> How does the client china.mytest.org now get the keys?
>> >> >
>> >> > Hi
>> >> > It doesn't need to. rpc.gssd can use any of the following keys:
>> >> > <HOSTNAME>$@<REALM>
>> >> > root/<hostname>@<REALM>
>> >> > nfs/<hostname>@<REALM>
>> >> > host/<hostname>@<REALM>
>> >> > root/<anyname>@<REALM>
>> >> > nfs/<anyname>@<REALM>
>> >> > host/<anyname>@<REALM>
>> >> >
>> >> > Just make sure that your keytab has one of them. Usually it will already
>> >> > have the CHINA$ key, so you can mount using that. The nfs server keytab
>> >> > should have both the nfs servivce and machine keys.
>> >> >
>> >> > There are many misunderstandings about kerberized nfs:
>> >> > http://linuxcostablanca.blogspot.com.es/2012/02/nfsv4-myths-and-legends.html
>> >> > HTH
>> >> > Steve
>> >>
>> >> What I did is:
>> >> 1. Have kadmind running on the kdc
>> >> 2. Run kadmin on the client as user root. A principal root@<REALM> exists
>> >> 3. Use ktadd in kamin to download the keys for
>> >> nfs/<clienthostname>@<REALM> and host/<clienthostname>@<REALM> .
>> >>
>> >> Still it does not work here and the mount fails:
>> >> mount -t nfs4 test1.mytest.org:/ /mnt
>> >> mount.nfs4: access denied by server while mounting nexentapuzzle.nrubsig.org:/
>> >
>> > Tell it to use Kerberos:
>> > mount -t nfs4 test1.mytest.org:/ /mnt -osec=krb5
>> >>
>> >> gssd is running:
>> >> # ps -ef | fgrep gss
>> >> root      1403     1  0 Mar18 ?        00:00:00 /usr/sbin/rpc.svcgssd
>> >> root      1420     1  0 Mar18 ?        00:00:00 /usr/sbin/rpc.gssd
>> >>
>> >> I have not a clue what I am doing wrong. Please help.
>> >
>> > Tell it to use Kerberos:
>> > mount -t nfs4 test1.mytest.org:/ /mnt -osec=krb5
>> >
>> > If still nothing send the output of:
>> > klist -ke
>> > on both the client and the server?
>>
>> @(nfs|krb) server (hostname "test1.mytest.org"):
>> # klist -ke /etc/krb5.keytab
>> Keytab name: WRFILE:/etc/krb5.keytab
>> KVNO Principal
>> ---- --------------------------------------------------------------------------
>>    2 nfs/test1 at TEST1.MYTEST.ORG (DES cbc mode with CRC-32)
>>    2 nfs/test1.mytest.org at TEST1.MYTEST.ORG (DES cbc mode with CRC-32)
>>    2 host/china.mytest.org at TEST1.MYTEST.ORG (AES-256 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    2 host/china.mytest.org at TEST1.MYTEST.ORG (AES-128 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    2 host/china.mytest.org at TEST1.MYTEST.ORG (Triple DES cbc mode with HMAC/sha1)
>>    2 host/china.mytest.org at TEST1.MYTEST.ORG (ArcFour with HMAC/md5)
>>    3 host/china.mytest.org at TEST1.MYTEST.ORG (AES-256 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    3 host/china.mytest.org at TEST1.MYTEST.ORG (AES-128 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    3 host/china.mytest.org at TEST1.MYTEST.ORG (Triple DES cbc mode with HMAC/sha1)
>>    3 host/china.mytest.org at TEST1.MYTEST.ORG (ArcFour with HMAC/md5)
>>    2 host/test1.mytest.org at TEST1.MYTEST.ORG (AES-256 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    2 host/test1.mytest.org at TEST1.MYTEST.ORG (AES-128 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    2 host/test1.mytest.org at TEST1.MYTEST.ORG (Triple DES cbc mode with HMAC/sha1)
>>    2 host/test1.mytest.org at TEST1.MYTEST.ORG (ArcFour with HMAC/md5)
>>    2 host/test1.mytest.org at TEST1.MYTEST.ORG (AES-256 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    2 host/test1.mytest.org at TEST1.MYTEST.ORG (AES-128 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    2 host/test1.mytest.org at TEST1.MYTEST.ORG (Triple DES cbc mode with HMAC/sha1)
>>    2 host/test1.mytest.org at TEST1.MYTEST.ORG (ArcFour with HMAC/md5)
>>    2 host/china.mytest.org at TEST1.MYTEST.ORG (AES-256 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    2 host/china.mytest.org at TEST1.MYTEST.ORG (AES-128 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    2 host/china.mytest.org at TEST1.MYTEST.ORG (Triple DES cbc mode with HMAC/sha1)
>>    2 host/china.mytest.org at TEST1.MYTEST.ORG (ArcFour with HMAC/md5)
>>    2 nfs/test1.mytest.org at TEST1.MYTEST.ORG (AES-256 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    2 nfs/test1.mytest.org at TEST1.MYTEST.ORG (AES-128 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    2 nfs/test1.mytest.org at TEST1.MYTEST.ORG (Triple DES cbc mode with HMAC/sha1)
>>    2 nfs/test1.mytest.org at TEST1.MYTEST.ORG (ArcFour with HMAC/md5)
>>    2 nfs/china.mytest.org at TEST1.MYTEST.ORG (AES-256 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    2 nfs/china.mytest.org at TEST1.MYTEST.ORG (AES-128 CTS mode with
>> 96-bit SHA-1 HMAC)
>>    2 nfs/china.mytest.org at TEST1.MYTEST.ORG (Triple DES cbc mode with HMAC/sha1)
>>    2 nfs/china.mytest.org at TEST1.MYTEST.ORG (ArcFour with HMAC/md5)
>>
>> Why do I have duplicate entries in this output? Are they harmful?
>
> They represent the different encryption types. They're not harmful but
> as this is the server, there is no need for the client keys. You can
> tidy it up using e.g. ktutil.
>>
>>
>> @(nfs|krb) client (hostname "china.mytest.org"):
>> # klist -ke
>> Keytab name: FILE:/etc/krb5.keytab
>> klist: No such file or directory while starting keytab scan
>>
>> Client is my problem, how can I get the keys to it? ssh them over?
>
> Working on the kdc, create a keytab (as you did above) with the machine
> key of the client, CHINA$, If you use ktutil, something like:
> wkt /tmp/china.keytab
>
> Then simply copy it to the client using scp or (even easier and more
> secure) using a USB memory stick. Rename china.keytab to krb5.keytab and
> copy it 0600 to /etc
>
>>
>> >
>> > What does /etc/exports look like on the server?
>>
>> # cat /etc/exports
>> /nfsv4krbtest   *(sec=krb5,rw,fsid=0
>
> Lose the fsid0. For now, replace the * with the IP of china
>
>> # uname -a
>> Linux test1.mytest.org 2.6.34.10-0.6-desktop #1 SMP PREEMPT 2011-12-13
>> 18:27:38 +0100 x86_64 x86_64 x86_64 GNU/Linux
>>
>> > Note that it is no longer recommended to export nfs4 as a fsid=0 pseudo
>> > root. Simply export it as we always have done nfs3.
>>
>> is this recommendation valid for the quite old 2.6.34.10-0.6-desktop
>> kernel in Suse 11.3?
>
> Dunno. Must it be nfs4 for anything in particular? Security perhaps?
> nfs3 works fine with kerberos.

NFSv4 is better for going through a firewall and is less sensitive to
hacking attempts.

But:
if I try to mount the share from the client I now see this:
Mar 19 23:03:42 test1 rpc.svcgssd[5154]: ERROR:
prepare_krb5_rfc_cfx_buffer: not implemented
Mar 19 23:03:42 test1 rpc.svcgssd[5154]: ERROR: failed serializing
krb5 context for kernel
Mar 19 23:03:42 test1 rpc.svcgssd[5154]: WARNING: handle_nullreq:
serialize_context_for_kernel failed
Mar 19 23:03:42 test1 rpc.svcgssd[5154]: ERROR:
prepare_krb5_rfc_cfx_buffer: not implemented
Mar 19 23:03:42 test1 rpc.svcgssd[5154]: ERROR: failed serializing
krb5 context for kernel
Mar 19 23:03:42 test1 rpc.svcgssd[5154]: WARNING: handle_nullreq:
serialize_context_for_kernel failed
Mar 19 23:03:43 test1 rpc.svcgssd[5154]: ERROR:
prepare_krb5_rfc_cfx_buffer: not implemented
Mar 19 23:03:43 test1 rpc.svcgssd[5154]: ERROR: failed serializing
krb5 context for kernel
Mar 19 23:03:43 test1 rpc.svcgssd[5154]: WARNING: handle_nullreq:
serialize_context_for_kernel failed
Mar 19 23:03:44 test1 rpc.svcgssd[5154]: ERROR:
prepare_krb5_rfc_cfx_buffer: not implemented
Mar 19 23:03:44 test1 rpc.svcgssd[5154]: ERROR: failed serializing
krb5 context for kernel
Mar 19 23:03:44 test1 rpc.svcgssd[5154]: WARNING: handle_nullreq:
serialize_context_for_kernel failed
Mar 19 23:04:29 test1 rpc.svcgssd[5154]: ERROR:
prepare_krb5_rfc_cfx_buffer: not implemented
Mar 19 23:04:29 test1 rpc.svcgssd[5154]: ERROR: failed serializing
krb5 context for kernel
Mar 19 23:04:29 test1 rpc.svcgssd[5154]: WARNING: handle_nullreq:
serialize_context_for_kernel failed
Mar 19 23:04:29 test1 rpc.svcgssd[5154]: ERROR:
prepare_krb5_rfc_cfx_buffer: not implemented
Mar 19 23:04:29 test1 rpc.svcgssd[5154]: ERROR: failed serializing
krb5 context for kernel
Mar 19 23:04:29 test1 rpc.svcgssd[5154]: WARNING: handle_nullreq:
serialize_context_for_kernel failed
Mar 19 23:04:30 test1 rpc.svcgssd[5154]: ERROR:
prepare_krb5_rfc_cfx_buffer: not implemented
Mar 19 23:04:30 test1 rpc.svcgssd[5154]: ERROR: failed serializing
krb5 context for kernel
Mar 19 23:04:30 test1 rpc.svcgssd[5154]: WARNING: handle_nullreq:
serialize_context_for_kernel failed
Mar 19 23:04:30 test1 rpc.svcgssd[5154]: ERROR:
prepare_krb5_rfc_cfx_buffer: not implemented
Mar 19 23:04:30 test1 rpc.svcgssd[5154]: ERROR: failed serializing
krb5 context for kernel
Mar 19 23:04:30 test1 rpc.svcgssd[5154]: WARNING: handle_nullreq:
serialize_context_for_kernel failed

Do you have a very, very bad English curse word which I can use to
swear at the machine? It doesn't have to be nice or politically
correct. Just very, very bad.

Oh, and I take any suggestions how to fix the 'rpc.svcgssd[5154]:
ERROR: prepare_krb5_rfc_cfx_buffer: not implemented' too.

Wendy

More information about the Kerberos mailing list