On 20 March 2014 00:04, Wendy Lin <wendlin1...@gmail.com> wrote: > On 19 March 2014 23:36, steve <st...@steve-ss.com> wrote: >> On Wed, 2014-03-19 at 23:16 +0100, Wendy Lin wrote: >>> On 19 March 2014 14:11, steve <st...@steve-ss.com> wrote: >>> > On Wed, 2014-03-19 at 13:32 +0100, Wendy Lin wrote: >>> >> On 19 March 2014 09:55, steve <st...@steve-ss.com> wrote: >>> >> > On Wed, 2014-03-19 at 00:09 +0100, Wendy Lin wrote: >>> >> >> On 18 March 2014 23:54, steve <st...@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....@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/te...@test1.mytest.org (DES cbc mode with CRC-32) >>> >> 2 nfs/test1.mytest....@test1.mytest.org (DES cbc mode with CRC-32) >>> >> 2 host/china.mytest....@test1.mytest.org (AES-256 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 2 host/china.mytest....@test1.mytest.org (AES-128 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 2 host/china.mytest....@test1.mytest.org (Triple DES cbc mode with >>> >> HMAC/sha1) >>> >> 2 host/china.mytest....@test1.mytest.org (ArcFour with HMAC/md5) >>> >> 3 host/china.mytest....@test1.mytest.org (AES-256 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 3 host/china.mytest....@test1.mytest.org (AES-128 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 3 host/china.mytest....@test1.mytest.org (Triple DES cbc mode with >>> >> HMAC/sha1) >>> >> 3 host/china.mytest....@test1.mytest.org (ArcFour with HMAC/md5) >>> >> 2 host/test1.mytest....@test1.mytest.org (AES-256 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 2 host/test1.mytest....@test1.mytest.org (AES-128 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 2 host/test1.mytest....@test1.mytest.org (Triple DES cbc mode with >>> >> HMAC/sha1) >>> >> 2 host/test1.mytest....@test1.mytest.org (ArcFour with HMAC/md5) >>> >> 2 host/test1.mytest....@test1.mytest.org (AES-256 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 2 host/test1.mytest....@test1.mytest.org (AES-128 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 2 host/test1.mytest....@test1.mytest.org (Triple DES cbc mode with >>> >> HMAC/sha1) >>> >> 2 host/test1.mytest....@test1.mytest.org (ArcFour with HMAC/md5) >>> >> 2 host/china.mytest....@test1.mytest.org (AES-256 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 2 host/china.mytest....@test1.mytest.org (AES-128 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 2 host/china.mytest....@test1.mytest.org (Triple DES cbc mode with >>> >> HMAC/sha1) >>> >> 2 host/china.mytest....@test1.mytest.org (ArcFour with HMAC/md5) >>> >> 2 nfs/test1.mytest....@test1.mytest.org (AES-256 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 2 nfs/test1.mytest....@test1.mytest.org (AES-128 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 2 nfs/test1.mytest....@test1.mytest.org (Triple DES cbc mode with >>> >> HMAC/sha1) >>> >> 2 nfs/test1.mytest....@test1.mytest.org (ArcFour with HMAC/md5) >>> >> 2 nfs/china.mytest....@test1.mytest.org (AES-256 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 2 nfs/china.mytest....@test1.mytest.org (AES-128 CTS mode with >>> >> 96-bit SHA-1 HMAC) >>> >> 2 nfs/china.mytest....@test1.mytest.org (Triple DES cbc mode with >>> >> HMAC/sha1) >>> >> 2 nfs/china.mytest....@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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos