Transferring NFSv4 nfs/ keys from KDC to client?
Wendy Lin
wendlin1974 at gmail.com
Wed Mar 19 19:52:40 EDT 2014
On 20 March 2014 00:04, Wendy Lin <wendlin1974 at gmail.com> wrote:
> On 19 March 2014 23:36, steve <steve at steve-ss.com> wrote:
>> On Wed, 2014-03-19 at 23:16 +0100, Wendy Lin wrote:
>>> 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
>>>
>> It doesn't like the encryption type. (On openSUSE 13.1 it's been fixed)
>> Try:
>> allow_weak_crypto = true
>> permitted_enctypes = "des-cbc-crc arcfour-hmac des3-cbc-sha1
>> aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96"
>>
>> to [libdefaults] in /etc/krb5.conf
>
> I have this now for [libdefaults]:
>
> ---------------------------------------------------
> [libdefaults]
> # default_realm = EXAMPLE.COM
>
> default_realm = TEST1.MYTEST.ORG
> clockskew = 300
> allow_weak_crypto = true
> permitted_enctypes = "des-cbc-crc arcfour-hmac des3-cbc-sha1
> aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96"
> ---------------------------------------------------
>
> is this what you wished to suggest? Client has the same
> permitted_enctypes, and I did a hard reboot of all machines.
>
> Unfortunately it does not work. Neither does this change+mount with NFSv3 btw
I tried permitted_enctypes = "des-cbc-crc des3-cbc-sha1" but this only
gives me a new kind of (its mocking me?!) error message in
/var/log/messages on the server:
rpc.svcgssd[6967]: qword_eol: fflush failed: errno 38 (Function not implemented)
Wendy
More information about the Kerberos
mailing list