linux-kernel - Re: ls input/output error ("NFS: readdir(/) returns -5") on krb5 NFSv4 client using SHA2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <85cd9202-dc22-41b8-8a20-e82cd118215f@TylerWRoss.com>
Date: Tue, 18 Nov 2025 23:43:29 +0000
From: "Tyler W. Ross" <TWR@...erwross.com>
To: Scott Mayhew <smayhew@...hat.com>
Cc: Trond Myklebust <trondmy@...nel.org>, Chuck Lever <chuck.lever@...cle.com>, Anna Schumaker <anna@...nel.org>, Salvatore Bonaccorso <carnil@...ian.org>, "1120598@...s.debian.org" <1120598@...s.debian.org>, Jeff Layton <jlayton@...nel.org>, NeilBrown <neil@...wn.name>, Steve Dickson <steved@...hat.com>, Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>, linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: ls input/output error ("NFS: readdir(/) returns -5") on krb5 NFSv4 client using SHA2

On 11/18/25 10:52 AM, Scott Mayhew wrote:
> Oh!  I see the problem.  If the automatically acquired service ticket
> for a normal user is using aes256-cts-hmac-sha1-96, then I'm assuming
> the machine credential is also using aes256-cts-hmac-sha1-96.
> Run 'klist -ce /tmp/krb5ccmachine_IPA.TWRLAB.NET' to check.  You can't
> use 'kvno -e' to choose a different encryption type.  Why are you doing
> that?

Aha! Thank you!

That's exactly the case: the machine credential is
aes256-cts-hmac-sha1-96.

So, taking a step back for context/background: this issue was escalated 
to me by someone attempting to use constrained delegation via gssproxy. 
In the course of troubleshooting that, we found (by examining the 
krb5kdc logs on the IPA server) that the NFS service ticket acquired by 
gssproxy had an aes256-cts-hmac-sha384-192 session key.

Not understanding that the machine and user tickets must having matching 
enctypes, I ended up down this rabbit hole thinking the problem was with 
the SHA2 enctypes. Sorry to bring you all with me on that misadventure.

The actual issue at hand then seems to be that gssproxy is requesting 
(and receiving) a service ticket with an unusable (for the NFS mount) 
enctype, when performing constrained delegation/S4U2Proxy.

krb5kdc logs of gssproxy performing S4U2Self and S4U2Proxy:Nov 18 
18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): TGS_REQ (8 etypes 
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), 
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), 
camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 10.108.2.105: 
ISSUE: authtime 1763506600, etypes {rep=aes256-cts-hmac-sha1-96(18), 
tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, 
host/nfsclient.ipa.twrlab.net@....TWRLAB.NET for 
host/nfsclient.ipa.twrlab.net@....TWRLAB.NET
Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): ... 
PROTOCOL-TRANSITION s4u-client=jsmith@....TWRLAB.NET
Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): closing 
down fd 4
Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): TGS_REQ (4 
etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), 
aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) 10.108.2.105: 
ISSUE: authtime 1763506600, etypes {rep=aes256-cts-hmac-sha1-96(18), 
tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)}, 
host/nfsclient.ipa.twrlab.net@....TWRLAB.NET for 
nfs/nfssrv.ipa.twrlab.net@....TWRLAB.NET
Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): ... 
CONSTRAINED-DELEGATION s4u-client=jsmith@....TWRLAB.NET
Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): closing 
down fd 11

On the Fedora 43 client, gssproxy also acquires an
aes256-cts-hmac-sha384-192 service ticket, but the machine credential is 
aes256-cts-hmac-sha384-192 and everything works as-expected.

TWR