Hi Salvatore
On 2025-03-16 16:52, Salvatore Bonaccorso wrote:
Hi Jostein
On Sun, Mar 16, 2025 at 02:53:14PM +0100, Jostein Fossheim wrote:
Package: nfs-kernel-server
Version: 1:2.6.2-4+deb12u1
Other relevant packages: gssproxy (0.9.1-1+b1), we have tested both with
rpc.svcgssd and gssproxy with seemingly similar results.
I am struggling in our lab to understand why my kerberized nfs-servers running
debian is not able to handle aes256-cts-hmac-sha384-192 /
aes128-cts-hmac-sha256-128 encryption.
We configured a freeIPA-enrolled Debian server, and configure our shares in a
similar way as on our Red Hat (RockyLinux) servers, and all clients got access
denied, while trying to mount the relevant shares.
After some investigation we saw the following we saw the following message in
the logs:
ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context():
GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more
information) - Encryption type aes256-cts-hmac-sha384-192 not permitted
The default keytabs provided via freeipa enrollment are the following (we add
the nfs-service-keytab manually)
klist -e -k /etc/krb5.keytab
Keytab name:FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1host/basic-nas.lab.skyfritt....@lab.skyfritt.net
(aes256-cts-hmac-sha384-192)
1host/basic-nas.lab.skyfritt....@lab.skyfritt.net
(aes128-cts-hmac-sha256-128)
1host/basic-nas.lab.skyfritt....@lab.skyfritt.net (aes256-cts-hmac-sha1-96)
1host/basic-nas.lab.skyfritt....@lab.skyfritt.net (aes128-cts-hmac-sha1-96)
1nfs/basic-nas.lab.skyfritt....@lab.skyfritt.net
(aes256-cts-hmac-sha384-192)
1nfs/basic-nas.lab.skyfritt....@lab.skyfritt.net
(aes128-cts-hmac-sha256-128)
1nfs/basic-nas.lab.skyfritt....@lab.skyfritt.net (aes256-cts-hmac-sha1-96)
1nfs/basic-nas.lab.skyfritt....@lab.skyfritt.net (aes128-cts-hmac-sha1-96)
So we tried to remove the"nfs/basic-nas.lab.skyfritt....@lab.skyfritt.net
(aes256-cts-hmac-sha384-192)"-keytab and tested again,
then we saw aes128-sha2 erros in the logs, only after we removed the"nfs/basic-nas.lab.skyfritt....@lab.skyfritt.net
(aes128-cts-hmac-sha256-128)" as well
our clients where able to mount their shares. So the following server-keytabs
are ok:
|
klist -e -k /etc/krb5.keytab
Keytab name:FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1host/basic-nas.lab.skyfritt....@lab.skyfritt.net
(aes256-cts-hmac-sha384-192)
1host/basic-nas.lab.skyfritt....@lab.skyfritt.net
(aes128-cts-hmac-sha256-128)
1host/basic-nas.lab.skyfritt....@lab.skyfritt.net (aes256-cts-hmac-sha1-96)
1host/basic-nas.lab.skyfritt....@lab.skyfritt.net (aes128-cts-hmac-sha1-96)
1nfs/basic-nas.lab.skyfritt....@lab.skyfritt.net (aes256-cts-hmac-sha1-96)
1nfs/basic-nas.lab.skyfritt....@lab.skyfritt.net (aes128-cts-hmac-sha1-96)
Having all the standard keytabs seems to be unproblematic on the client side.
We have tried to install gssproxy as well on our servers, but the same access
denied messages are occurring but the log-messages are more dubious
when we use the encryption-/hashing-schemas in question. We have experimented
quite a bit, and cannot understand why Debian nfs-servies should not be able to
accept
aes256-cts-hmac-sha384-192 and aes128-cts-hmac-sha256-128 tickets which our Red
Hat / Rocky Servers are.
Setting things like:
permitted_enctypes =
aes256-cts-hmac-sha384-192,aes128-cts-hmac-sha256-128,aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96
default_tkt_enctypes =
aes256-cts-hmac-sha384-192,aes128-cts-hmac-sha256-128,aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96
default_tgs_enctypes =
aes256-cts-hmac-sha384-192,aes128-cts-hmac-sha256-128,aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96
Seems to have no effect.
I think this is not a nfs-utils issue itself but we have not enabled
CONFIG_RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA2 in the kernel for Debian
(only available with a40cf7530d31 ("SUNRPC: Add gk5e definitions for
RFC 8009 encryption types") in 6.3-rc1 onwards):
config RPCSEC_GSS_KRB5_ENCTYPES_AES_SHA2
bool "Enable Kerberos enctypes based on AES and SHA-2"
depends on RPCSEC_GSS_KRB5
depends on CRYPTO_CBC && CRYPTO_CTS
depends on CRYPTO_HMAC && CRYPTO_SHA256 && CRYPTO_SHA512
depends on CRYPTO_AES
default n
help
Choose Y to enable the use of Kerberos 5 encryption types
that utilize Advanced Encryption Standard (AES) ciphers and
SHA-2 digests. These include aes128-cts-hmac-sha256-128 and
aes256-cts-hmac-sha384-192.
Can you please confirm by doing a kernel build e.g. with version
available in bookworm-backports, which would be recent enough with
this enabled make your setup work?
For you though I think the following might be relevant to help making
setups with "old" kernel work, would be great if you can confirm that
as well:
https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=9b1f860a3457328a08395651d029a454e0303454
Note that though this only landed in nfs-utils-2-7-1-rc5 and you have
it not available in nfs-utils in Debian bookworm.
But that said the situation in Bookworm might not be optimal for
kerberized NFS setups.
Regards,
Salvatore
Thank you for you're response, I am pleased that there seems to be a
logical answer to this problem.
I can do whatever tests you want me to, we are studying the situation in
a lab-environment and setup the servers via Ansible-playbooks and
zfs-snapshotting, so my next plan was to test with Trixie. Is the
encryption types included in the default kernel there?
I will try allowed-enctypes on our clients as explained in the commit
from the link, and try a custom-kernel build as suggested.
I will report back as soon as possible, probably on Monday.
--
Vennlig Hilsen
Jostein Fossheim
