Am un server NFS kerberizat care funcționează. Funcționează amenda cu MacOS, Debian (Sid) și Raspbian. Nu funcționează cu Impish Indri și nu-mi dau seama de ce.
- Autentificarea GSSAPI cu SSH funcționează bine cu Impish
- Am cheia nfs/ și nu folosește cifrurile depreciate:
sudo klist -e -k /etc/krb5.keytab
Nume tasta de taste: FILE:/etc/krb5.keytab
Principalul KVNO
---- --------------------------------------------- ----------------------------
4 nfs/[email protected] (aes256-cts-hmac-sha1-96)
4 nfs/[email protected] (aes128-cts-hmac-sha1-96)
4 host/[email protected] (aes256-cts-hmac-sha1-96)
4 host/[email protected] (aes128-cts-hmac-sha1-96)
/srv/video *(rw,async,mp,root_squash,no_subtree_check,nesecure,sec=krb5p)
Și așa cum am spus - pe orice sistem de operare pe care l-am încercat cu exceptia ticălos, munci muncește.
Totuși, despre ticăloșie, primesc întotdeauna:
mount -t nfs4 -o rw,soft,sec=krb5p server.foo.net:/srv/video /mnt
mount.nfs4: a fost specificată o opțiune de montare incorectă
Am pornit înregistrarea prin intermediul RPCGSSDOPTS="-vvvrr" asupra clientului și a prietenului său RPCSVCGSSDOPTS="-vvvrr" pe server.
Dacă orice altă gazdă încearcă să monteze prin NFS -- rpc.svcgssd are ieșirea obișnuită pe server:
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: ieșire din sondaj
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: gestionarea cererii nule
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: svcgssd_limit_krb5_enctypes: Apelarea gss_set_allowable_enctypes cu 6 enctypes din nucleu
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: sname = [email protected]
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: se efectuează apel
13 ian 08:44:33 server rpc.svcgssd[1681508]: mech: krb5, hndl len: 4, ctx len 52, timeout: 1642124615 (35942 de acum), clnt: <null>, uid: gid: 1000, uid: gid: 1000 , num grps aux: 21:
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: (1) 1000
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 2) 27
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 3) 100
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: ( 4) 123
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 5) 30
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: ( 6) 1005
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 7) 4
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 8) 20
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 9) 24
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 10) 29
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 11) 34
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 12) 40
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 13) 44
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 14) 46
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 15) 102
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 16) 116
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: ( 17) 1006
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 18) 111
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 19) 151
13 ian 08:44:33 server rpc.svcgssd[1681508]: ( 20) 157
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: ( 21) 1011
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: trimiterea răspunsului nul
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: scrierea mesajului: <Șir de date hext>
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: finalizat gestionarea cererii nule
13 ianuarie 08:44:33 server rpc.svcgssd[1681508]: intrarea în sondaj
, și rpc.gssd are rezultatul așteptat pentru client
handle_gssd_upcall: 'mech=krb5 uid=0 service=* enctypes=18,17,16,3,1,2' (nfs/clnt25)
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: krb5_use_machine_creds: uid 0 tgtname (null)
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: Numele de gazdă complet pentru „server.foo.net” este „server.foo.net”
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: Numele de gazdă complet pentru „tock.foo.net” este „tock.foo.net”
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: Nu s-a găsit nicio intrare în tabelul de chei pentru [email protected] în timp ce se obține intrarea în tabelul de taste pentru „[email protected]”
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: Nu a fost găsită nicio intrare în tabelul de chei pentru [email protected] în timp ce se obține intrarea în tabelul de chei pentru „[email protected]”
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: Nu s-a găsit nicio intrare în tabelul cheie pentru root/[email protected] în timp ce se obține intrarea keytab pentru „root/tock.foo.net@ FOO.NET'
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: Reușită obținerea intrării keytab pentru „nfs/[email protected]”
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: INFORMAȚII: Acreditările în CC „FILE:/tmp/krb5ccmachine_FOO.NET” sunt bune până la 1642095679
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: INFORMAȚII: Acreditările în CC „FILE:/tmp/krb5ccmachine_FOO.NET” sunt bune până la 1642095679
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: crearea clientului tcp pentru server server.foo.net
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: DEBUG: port deja setat la 2049
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: crearea contextului cu serverul [email protected]
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: în authgss_create_default()
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: în authgss_create()
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: în authgss_refresh()
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: Jetonul trimis (lungime 673):
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: în authgss_marshal()
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: xdr_rpc_gss_buf: codificare succes ((nil):0)
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: xdr_rpc_gss_cred: codificare succes (v 1, proc 1, seq 0, svc 1, ctx (nil):0)
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: în authgss_wrap()
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: xdr_rpc_gss_buf: codificare succes (0x7620c680:673)
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: xdr_rpc_gss_init_args: codificare succes (token 0x7620c680:673)
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: în authgss_validate()
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: în authgss_unwrap()
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: xdr_rpc_gss_buf: decodare reușită (0x7620ea50:4)
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: xdr_rpc_gss_buf: decodare reușită (0x762047a8:156)
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: xdr_rpc_gss_init_res decode succes (ctx 0x7620ea50:4, maj 0, min 0, win 128, token 0x7820467)
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: Jetonul pe care tocmai l-am primit (lungimea 156):
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: în authgss_get_private_data()
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: se efectuează downcall: lifetime_rec=7007 [email protected]
13 ianuarie 08:44:32 tock.foo.net rpc.gssd[5440]: în authgss_free_private_data()
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: în authgss_destroy()
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]: în authgss_destroy_context()
13 ian 08:44:32 tock.foo.net rpc.gssd[5440]:
-- și funcționează pe MacOS, Debian (Sid), Raspbian etc.
Cu toate acestea, când încerc să folosesc impish -- nimic nu lovește serverul (fără jurnalele pentru rpc.svcgssd, și rpc.gssd nu apare orice activitate asupra clientului. Mi-ar plăcea să arăt ce se întâmplă, dar impish nu furnizează niciun fel de date, cu excepția a fost specificată o opțiune de montare incorectă oricând sec=krb5p este furnizat.
Nu înţeleg. Este NFS kerberizat rupt în impish?
