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 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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
