Configurei o NFS/Keberos com êxito, mas estou tendo problemas com permissões quando um usuário autenticado Kerberos emite uma gravação, que gera o seguinte:
philip@client $: touch /mnt/philip/testfile.txt
touch: cannot touch '/mnt/philip/test': Permission denied
Abaixo está minha instalação e configurações completas:
mydomain.net
é um espaço reservado
Configurar servidor NFS
server #: apt-get -y update
server #: apt-get -y install nfs-kernel-server nfs-common
server #: mkdir -p /srv/nfs/philip
server #: cat <<EOF >>/etc/exports
/srv/nfs/philip 192.168.10.0/24(rw,nohide,insecure,no_subtree_check,sync,no_root_squash)
EOF
server #: service nfs-kernel-server restart
Cliente de configuração
client #: apt-get -y update
client #: apt-get -y install nfs-common
client #: mkdir -p /mnt/philip
client #: cat <<EOF >>/etc/fstab
nfs.mydomain.net:/srv/nfs/nfs-001 /mnt/philip nfs defaults 0 0
EOF
client #: mount -a
Teste
O compartilhamento NFS agora deve ser montado em /mnt/philip
. ISSO FUNCIONA!
Configuração Kerberos
Servidor
Atualização /etc/exports
para refletir o novo compartilhamento Kerberos:
/srv/nfs/philip 192.168.10.0/24(sec=krb5p,rw,nohide,insecure,no_subtree_check,sync)
Obs: retirei no_root_squash
aqui.
e exportar:
server #: exportfs -ra
server #: showmount -e
Agora configure o servidor Kerberos:
server #: apt install krb5-kdc krb5-admin-server #enter realm in full caps, enter fqdn for hostnames
server #: cat /etc/krb5.conf
[libdefaults]
default_realm = MYDOMAIN.NET
# The following krb5.conf variables are only for MIT Kerberos.
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
rdns = false
# The following libdefaults parameters are only for Heimdal Kerberos.
fcc-mit-ticketflags = true
[realms]
MYDOMAIN.NET = {
kdc = nfs.mydomain.net
admin_server = nfs.mydomain.net
}
[domain_realm]
continuar a configuração...
server #: krb5_newrealm
server #: vi /etc/krb5kdc/kadm5.acl # uncomment /*admin *
server #: systemctl restart krb5-kdc krb5-admin-server
server #: kadmin.local -q "addprinc admin/[email protected]"
# setup principal for NFS Service on NFS Server
server #: kadmin.local -q "addprinc -randkey nfs/[email protected]"
server #: kadmin.local -q "ktadd -k /etc/krb5.keytab nfs/[email protected]"
Cliente de configuração
Ainda no servidor:
server #: kadmin.local -q "addprinc -randkey nfs/[email protected]"
server #: kadmin.local -q "ktadd -k /etc/krb5.client.keytab nfs/[email protected]"
server #: scp /etc/krb5.client.keytab client:/etc/krb5.keytab
Então no cliente:
client #: apt update
client #: apt install krb5-user
client #: kinit -k -t /etc/krb5.keytab nfs/[email protected]
client #: klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: nfs/[email protected]
Valid starting Expires Service principal
11/27/2023 14:49:54 11/28/2023 00:49:54 krbtgt/[email protected]
renew until 11/28/2023 14:49:44
Agora posso montar o compartilhamento NFS com autenticação Kerberos:
mount -a
Observe que tenho nfs.mydomain.net:/srv/nfs/philip /mnt/philip nfs sec=krb5p 0 0
no meu arquivo /etc/fstab
.
se isso falhar, você pode precisar:
systemctl restart rpc-gssd
Status
O NFS agora está montado na máquina cliente via Kerberos
Configure o Philip para acessar o compartilhamento NFS/Keberos
# setup principal for Philip
server #: kadmin.local -q "addprinc -randkey philip/[email protected]"
server #: kadmin.local -q "ktadd -k /etc/krb5.philip.keytab philip/[email protected]"
server #: scp /etc/krb5.philip.keytab client:
então autentique:
philip@client $: kinit -k -t krb5.philip.keytab philip/[email protected]
philip@client $: ls -ls /mnt/philip
total 12
drwxr-xr-x 2 philip philip 4096 Dec 26 07:30 .
drwxr-xr-x 7 root root 4096 Dec 26 09:34 ..
philip@client $: touch /mnt/philip/test
touch: cannot touch '/mnt/philip/test': Permission denied
aqui estão as permissões:
server #: ls -la /srv/nfs/
total 16
drwxr-xr-x 4 root root 4096 Dec 26 06:35 .
drwxr-xr-x 3 root root 4096 Dec 22 14:35 ..
drwxr-xr-x 2 philip philip 4096 Dec 26 07:30 philip
root não pode nem gravar neste diretório.
Se eu chmod 777 /srv/nfs/philip
puder escrever, isso indica que sou um other
usuário.
para onde ir a partir daqui?
Agradeço qualquer ajuda para solucionar isso.
O mapeamento padrão de entidades Kerberos para contas Unix conhece apenas nomes de entidades de 1 componente; ou seja, o servidor sabe como mapear
[email protected]
para sua conta Unixphilip
, mas não possui suporte integrado 1 para principais que usam instâncias – então, o principal é mapeadonobody
.Em geral, não use entidades de instância para contas de usuário, a menos que você saiba que deseja fazê-lo especificamente. Na maioria dos casos,
[email protected]
é o que você deveria ter criado para a conta do usuário (e, normalmente, usado uma senha normal em vez de um keytab). Mas se você precisar de entidades de usuário com um nome de instância, precisará definir regras de mapeamento para elas.(E, diferentemente das entidades de serviço, não há nenhum significado especial em usar um FQDN para a instância de uma conta de usuário, exceto em algumas configurações personalizadas. Mais comumente, a instância de uma entidade de usuário seria algo como
philip/admin
ou/cron
– uma sequência arbitrária em vez de um nome de host. )A autenticação no NFS acontece na camada SunRPC, portanto a tradução principal → nome de usuário funciona separadamente de 'idmapd' (que é apenas para tradução nome de usuário⇆UID e usada apenas para "carga útil" NFS, como o UID/GID mostrado em
ls -l
); em vez disso, a tradução é feita em 'gssproxy' (ou o antigo 'rpc.svcgssd') de acordo com as regras de mapeamento padrão da libkrb5 definidas em/etc/krb5.conf
.Portanto, se você precisar usar entidades de usuário com instâncias, seria assim para o MIT Kerberos:
(...significando "se o principal tiver
2
componentes, combine-os em '$1;$2@$0
' e compare com o regex /.*@MYDOMAIN\.NET$
/; se corresponder, faça uma substituição de regex /@.*$
/ por '' e o resultado será o nome de usuário".)
Isso cobrirá não apenas o NFS, mas também o SSH e a maioria dos outros serviços baseados em Kerberos (qualquer coisa que use as funções
gss_localname()
oukrb5_aname_to_localname()
).Um problema com instâncias baseadas em host é que você precisará de uma regra genérica que inevitavelmente também se aplicará aos principais de serviço, por exemplo, cada 'host/foo.example.com' agora será mapeado para o usuário 'host'.
1 (Pode ser porque o Kerberos não consegue distinguir facilmente os principais de usuário com uma instância dos principais de serviço que usam exatamente a mesma sintaxe – ou talvez o uso de principais de usuário instanciados quase sempre acompanha algum tipo de mapeamento não padrão.)