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 ---- -------------------------------------------------------------------------- 1 host/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes256-cts-hmac-sha384-192) 1 host/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes128-cts-hmac-sha256-128) 1 host/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes256-cts-hmac-sha1-96) 1 host/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes128-cts-hmac-sha1-96) 1 nfs/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes256-cts-hmac-sha384-192) 1 nfs/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes128-cts-hmac-sha256-128) 1 nfs/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes256-cts-hmac-sha1-96) 1 nfs/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes128-cts-hmac-sha1-96) So we tried to remove the "nfs/basic-nas.lab.skyfritt.net@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.net@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 ---- -------------------------------------------------------------------------- 1 host/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes256-cts-hmac-sha384-192) 1 host/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes128-cts-hmac-sha256-128) 1 host/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes256-cts-hmac-sha1-96) 1 host/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes128-cts-hmac-sha1-96) 1 nfs/basic-nas.lab.skyfritt.net@LAB.SKYFRITT.NET (aes256-cts-hmac-sha1-96) 1 nfs/basic-nas.lab.skyfritt.net@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