Eu tenho dois sistemas em uma rede local, nfsclient (CentOS 7) e nfsserver (CentOS 6). Esses nomes resolvem corretamente para seus endereços IP, e o Kerberos está trabalhando entre eles (nfsserver é o KDC). Eu tenho um compartilhamento NFSv4 Kerberized exportado no nfsserver; my / etc / exports é o seguinte:
/export *(rw,sync,fsid=0,no_subtree_check,sec=krb5p)
/export/home *(rw,sync,no_subtree_check,no_root_squash,sec=krb5p)
Eu posso ver essas exportações do nfsclient:
[root@nfsclient ~]# showmount -e nfsserver
Export list for nfsserver:
/export/home *
/export *
Se eu remover as opções sec = krb5p em / etc / exports, posso montar o compartilhamento do nfsclient usando
[root@nfsclient ~]# mount -t nfs4 nfsserver:/ /mnt/nfs
Quando o NFS é kerberizado, no entanto, as coisas não correm bem:
[root@nfsclient ~]# mount -t nfs4 -o sec=krb5p nfsserver:/ /mnt/nfs
mount.nfs4: access denied by server while mounting nfsserver:/
Isto é acompanhado por uma série de mensagens de erro repetidas em / var / log / messages:
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
Jun 22 19:55:02 oxo gssproxy: gssproxy[769]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more information, No credentials cache found
Nada aparece nos logs do servidor. A execução da klist no cliente mostra que o root tem um cache de credenciais em / tmp / krb5cc_0, por isso sou levado a pensar que há um problema com o gss-proxy.
/etc/gssproxy/gssproxy.conf:
[gssproxy]
[service/HTTP]
mechs = krb5
cred_store = keytab:/etc/gssproxy/http.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
euid = 48
[service/nfs-server]
mechs = krb5
socket = /run/gssproxy.sock
cred_store = keytab:/etc/krb5.keytab
trusted = yes
kernel_nfsd = yes
euid = 0
[service/nfs-client]
mechs = krb5
cred_store = keytab:/etc/krb5.keytab
cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U
cred_store = client_keytab:/var/lib/gssproxy/clients/%U.keytab
cred_usage = initiate
allow_any_uid = yes
trusted = yes
euid = 0
Portanto, o gss-proxy deve estar procurando pelo cache de credenciais em / var / lib / gssproxy / clients. Ele também está obtendo chaves de /etc/krb5.keytab (que possui chaves para os principais nfs / nfsclient e host / nfsclient). No entanto, / var / lib / gssproxy / clients parece estar sempre vazio no nfsclient.
Estou sentindo falta de algo aqui? Eu não consigo descobrir o que exatamente está errado com a montagem deste compartilhamento.
Existe um problema com a configuração do arquivo padrão na definição do caminho do cache. Experimente com esta configuração do cliente, em /etc/gssproxy/gssproxy.conf :
[service/nfs-client]
mechs = krb5
cred_store = keytab:/etc/krb5.keytab
cred_store = ccache:FILE:/tmp/krb5cc_%U
cred_usage = initiate
allow_any_uid = yes
trusted = yes
euid = 0
debug = true
verifique se seu cliente ingressou no domínio.
ipa-client-install --force-join
Depois, verifique se você tem um ingresso
kinit admin
e, em seguida, verifique novamente o krb5.keytab
restorecon -v /etc/krb5.keytab
garanta que seu cliente esteja no keytab
kinit -k
host/ < client > . < domain > @REALM
Você deve ser capaz de montar com sec=krb5p