Início / unix / Perguntas / 688126
Accepted
Dylan L
Asked: 2022-01-27 21:34:55 +0800 CST

Permissão NFS negada com sec=krb5p

  • 772

Estou configurando o NFSv4.2 com MIT Kerberos ( sec=krb5p) em duas VMs Hyper-V executando o Debian 11 (Bullseye). Quando uso autenticação baseada em máquina ( sec=sys), tudo funciona bem. Com o Kerberos ( sec=krb5p), consigo montar o compartilhamento no cliente, mas vejo Permission deniedquando tento acessar o compartilhamento. Documentei tudo isso em detalhes abaixo, incluindo todas as informações de configuração relevantes que me vieram à mente. Estou um pouco fora da minha profundidade. O que estou perdendo ou fazendo errado?

NFS trabalha comsec=sys

/etc/exports no servidor:

/exports/ned 192.168.1.0/24(sec=sys,rw,no_subtree_check)

/etc/fstab no cliente:

test-debian-server:/exports/ned /imports/ned nfs sec=sys 0 0

Testando o compartilhamento:

ned@test-debian-desktop:/imports$ su - -c "nfsstat -m"
Password:
/imports/ned from test-debian-server:/exports/ned
 Flags: rw,relatime,vers=4.2,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.63,local_lock=none,addr=192.168.1.62

ned@test-debian-desktop:/imports$ id
uid=2001(ned) gid=2001(ned) groups=2001(ned)
ned@test-debian-desktop:/imports$ ls -l
total 4
drwxr-xr-x 2 ned ned 4096 Jan 26 17:57 ned
ned@test-debian-desktop:/imports$ cd ned
ned@test-debian-desktop:/imports/ned$ ls
ned@test-debian-desktop:/imports/ned$ touch test.txt
ned@test-debian-desktop:/imports/ned$ ls
test.txt

Verificando test.txt no servidor:

ned@test-debian-server:/exports$ id
uid=2001(ned) gid=2001(ned) groups=2001(ned)
ned@test-debian-server:/exports$ ls -l
total 4
drwxr-xr-x 2 ned ned 4096 Jan 26 19:11 ned
ned@test-debian-server:/exports$ ls -l ned
total 0
-rw-r--r-- 1 ned ned 0 Jan 26 19:11 test.txt

Permissão negada comsec=krb5p

Configuração do servidor

/etc/hosts:

127.0.0.1       localhost
127.0.1.1       test-debian-server.test test-debian-server
192.168.1.63    test-debian-desktop
192.168.1.62    test-debian-server

/etc/default/nfs-kernel-server:

RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids"
NEED_SVCGSSD=""
RPCSVCGSSDOPTS=""

/etc/default/nfs-common:

NEED_STATD=
STATDOPTS=
NEED_IDMAPD=
NEED_GSSD=

/etc/exports:

/exports/ned 192.168.1.0/24(sec=krb5p,rw,no_subtree_check)

/etc/krb5.conf (bastante abreviado):

[libdefaults]
        default_realm = TEST

        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

[realms]
        TEST = {
                kdc = test-debian-server
                admin_server = test-debian-server
        }

Principais Kerberos:

root@test-debian-server:~# kadmin.local listprincs
K/M@TEST
host/test-debian-desktop@TEST
host/test-debian-server@TEST
kadmin/admin@TEST
kadmin/changepw@TEST
kadmin/test-debian-server@TEST
kiprop/test-debian-server@TEST
krbtgt/TEST@TEST
nfs/test-debian-desktop@TEST
nfs/test-debian-server@TEST

Tecla do Kerberos:

root@test-debian-server:~# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 nfs/test-debian-server@TEST (aes256-cts-hmac-sha1-96)
   2 nfs/test-debian-server@TEST (aes128-cts-hmac-sha1-96)
   2 host/test-debian-server@TEST (aes256-cts-hmac-sha1-96)
   2 host/test-debian-server@TEST (aes128-cts-hmac-sha1-96)

Domínio efetivo do NFS:

root@test-debian-server:~# nfsidmap -d
test

Permissões nas exportações:

root@test-debian-server:~# ls -ld /exports /exports/*
drwxr-xr-x 3 root root 4096 Jan 26 17:58 /exports
drwxr-xr-x 2 ned  ned  4096 Jan 26 19:11 /exports/ned

Configuração do cliente

/etc/hosts:

127.0.0.1       localhost
127.0.1.1       test-debian-desktop.test        test-debian-desktop
192.168.1.63    test-debian-desktop
192.168.1.62    test-debian-server

/etc/default/nfs-common: igual ao server.

/etc/fstab:

test-debian-server:/exports/ned /imports/ned nfs sec=krb5p 0 0

/etc/krb5.conf: igual ao servidor.

Tecla do Kerberos:

root@test-debian-desktop:~# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   3 nfs/test-debian-desktop@TEST (aes256-cts-hmac-sha1-96)
   3 nfs/test-debian-desktop@TEST (aes128-cts-hmac-sha1-96)
   2 host/test-debian-desktop@TEST (aes256-cts-hmac-sha1-96)
   2 host/test-debian-desktop@TEST (aes128-cts-hmac-sha1-96)

Domínio efetivo do NFS:

root@test-debian-desktop:~# nfsidmap -d
test

Permissões nas importações (após desmontar o compartilhamento):

root@test-debian-desktop:~# umount /imports/ned
root@test-debian-desktop:~# ls -ld /imports /imports/*
drwxr-xr-x 3 root root 4096 Jan 26 19:08 /imports
drwxr-xr-x 2 root root 4096 Jan 26 17:02 /imports/ned

(Observação: obtenho o mesmo resultado quando chown ned:ned /imports/ned. Acho que root:rootestá correto, para evitar nedgravar acidentalmente no disco local se a montagem falhar?)

Permissão negada

Após reiniciar o servidor e o cliente:

ned@test-debian-desktop:/imports$ su -c "nfsstat -m"
Password:
/imports/ned from test-debian-server:/exports/ned
 Flags: rw,relatime,vers=4.2,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5p,clientaddr=192.168.1.63,local_lock=none,addr=192.168.1.62

ned@test-debian-desktop:/imports$ ls -l
total 4
drwxr-xr-x 2 ned ned 4096 Jan 26 19:11 ned
ned@test-debian-desktop:/imports$ cd ned
bash: cd: ned: Permission denied
ned@test-debian-desktop:/imports$

Às vezes ned, pode listar o compartilhamento ls -linicialmente, mas não pode cdentrar nele, como na sessão acima; um minuto depois, se nedtentar ls -l, eles verão Permission deniede pontos de interrogação para os nedatributos da pasta. Quando isso acontece, posso fazer o seguinte:

ned@test-debian-desktop:/imports$ ls -l
ls: cannot access 'ned': Permission denied
total 0
d????????? ? ? ? ?            ? ned
ned@test-debian-desktop:/imports$ su -c "ls -l /imports"
Password:
total 4
drwxr-xr-x 2 ned ned 4096 Jan 26 19:11 ned
ned@test-debian-desktop:/imports$ ls -l
total 4
drwxr-xr-x 2 ned ned 4096 Jan 26 19:11 ned
ned@test-debian-desktop:/imports$

Isso parece ser devido à expiração do cache de atributo: se eu desabilitar o cache de atributo noacem /etc/fstab no cliente e remontá-lo, nedverá de forma confiável Permission deniede pontos de interrogação ao chamar ls -l.

O que eu tentei

Tanto no cliente quanto no servidor, eu tenho:

  • Definir Verbosity = 4em/etc/idmapd.conf
  • Usado rpcdebugpara definir todos os sinalizadores para nfs,nfsd , nlmerpc
  • Vasculhou o diário do systemd em busca de informações relevantes (depois de reinicializar e tentar acessar o compartilhamento).

Verifiquei systemctl statusse as seguintes unidades estãoactive , e li as entradas de diário recentes listadas para cada uma (e não encontrei indicadores óbvios do que está errado):

  • Servidor:
    • krb5-admin-servidor
    • krb5-kdc
    • nfs-kernel-server
    • nfs-idmapd
    • nfs-mountd
    • servidor nfs
    • rpc-svcgssd
    • rpc-gssd
  • Cliente:
    • rpc-gssd
    • imports-ned.mount

Tanto quanto posso dizer, o Kerberos está autenticando corretamente.

Li todas as páginas de manual relevantes e manuais on-line que posso encontrar e todas as perguntas no StackExchange que pareciam estar relacionadas, e não consegui corrigir o problema ou fazer com que o cliente ou o servidor gerasse uma mensagem de erro para me informar por que a permissão está sendo negada.

Editado para adicionar host/test-debian-desktope host/test-debian-serverprincipais e chaves Kerberos de acordo com Unix Application Servers - MIT Kerberos Documentation

O que estava faltando

A resposta escolhida faz um bom trabalho ao explicar o motivo pelo qual minha configuração não estava funcionando. Caso alguém esteja na mesma situação, aqui estão os detalhes do que estava faltando - e leia a resposta abaixo para saber o porquê.

O Kerberos autentica usuários individuais (o que, por algum motivo, pensei que não). Portanto, para nedse conectar, o Kerberos deve ter um ned@TESTprincipal e o usuário do Linux nedno PC cliente deve kinitobter um Ticket-Granting Ticket (TGT) para esse principal. Então tudo funciona lindamente. Para automatizar mais ou menos isso, fiz o seguinte:

/etc/krb5/user/<uid>/client.keytab: contém chaves para nede só é legível por ned! Eu usei 0600permissões, com proprietário e grupo tanto como ned.

Com este keytab, posso simplesmente invocar kinit -kipara fazer login sem precisar digitar uma senha. A maneira rápida e suja de automatizar isso foi adicioná-lo a ~/.gnomerc, ~/.bashrc ~/.zshrc (já que eu uso Gnome, Bash e Zsh).

Além disso, como implemento essas configurações via Ansible e tenho alguns sistemas que compartilham dotfiles, mas não precisam de acesso NFS, fiquei um pouco mais sofisticado com Bash e Zsh, executando apenas kinitse ele e o keytab do cliente estiverem presentes:

~/.bashrc:

# Grab or renew a Kerberos ticket.
if type -t kinit >/dev/null && [[ -r /etc/krb/user/$(id -u)/client.keytab ]]
then
  kinit -ki
fi

~/.zshrc:

# Grab or renew a Kerberos ticket.
if type kinit >/dev/null && [[ -r /etc/krb/user/$(id -u)/client.keytab ]]
then
  kinit -ki
fi
linux debian

1 respostas

  1. Best Answer

    A razão pela qual você obteve "permissão negada" foi porque você não tinha um Kerberos TGT (ticket-granting-ticket) em seu cache de credenciais, como você pode ver na saída do arquivo klist. Você tinha que correr kinitpara a conta e digitar sua senha. Depois de autenticar e ter um tíquete TGT armazenado em cache, você pode usar esse tíquete para autenticar no servidor NFS.

    Você precisa lembrar que toda a ideia da autenticação Kerberos é que você precisa "provar" sua identidade para o servidor NFS (ou qualquer outro serviço). Você "prova" apresentando seu TGT em cache que você gerou digitando sua senha (que só você conhece) ao kinitcomando. Então geralmente é assim que deve funcionar. Você pode alterar os tempos de expiração e renovação em seu krb5/ sssd/qualquer coisa para fazer com que seus ingressos durem mais antes de expirar, mas eventualmente em algum momento você precisará autenticar novamente de uma forma ou de outra.

    Claro que você sempre pode criar um keytab para sua conta. Não o adicione ao keytab do cliente! O keytab do cliente é apenas para o cliente . Você precisará criar um novo keytab em um novo arquivo para sua conta e manter esse arquivo seguro e privado com permissões mínimas e usar esse keytab para gerar o TGT em seu cache de credenciais sem digitar uma senha interativamente. Teoricamente você pode até criar um crontabque faça isso por você periodicamente, mas isso é menos seguro, pois alguém pode roubar seu keytab em algum momento (se tiver acesso root, por exemplo) e fingir ser você para outros serviços, mas isso é para sua consideração.

    Além disso, se você estiver seguindo o caminho do keytab, não esqueça que sempre que alterar a senha da conta, também precisará atualizar seu keytab.

    • 1

relate perguntas