Re: [PATCH] t7528: work around ETOOMANY in OpenSSH 10.1 and newer

[Patrick Steinhardt <ps@pks.im>]

On Thu, Oct 23, 2025 at 08:43:20AM -0400, Jeff King wrote:
> On Thu, Oct 23, 2025 at 09:14:59AM +0200, Patrick Steinhardt wrote:
> 
> > As it turns out this is caused by a change in OpenSSH 10.1 [1]:
> > 
> >  * ssh-agent(1), sshd(8): move agent listener sockets from /tmp to
> >    under ~/.ssh/agent for both ssh-agent(1) and forwarded sockets
> >    in sshd(8).
> > 
> > Instead of creating the socket in "/tmp", OpenSSH now creates the socket
> > in our home directory. And as the home directory gets modified to be
> > located in our test output directory we end up with paths that are
> > somewhat long. But Linux has a rather short limit of 108 characters for
> > socket paths, and other systems have even lower limits, so it is very
> > easy now to exceed the limit and run into the above error.
> 
> There's a secondary issue, too: even if the path is short enough, the
> space in "trash directory" of the path will break the shell eval. That's
> relevant below.
> 
> > Work around the issue by using `ssh-agent -T`, which instructs it to
> > use the old behaviour and create the socket in "/tmp" again. This switch
> > has only been introduced with 10.1 though, so for older versions we have
> > to fall back to not using it. That's fine though, as older versions know
> > to put the socket into "/tmp" already.
> 
> OK. I think this is an improvement over the status quo, though it leaves
> a lot of loose ends, like:
> 
>   - what happens if "ssh-agent" does not exist at all; we do not notice
>     the error because the eval succeeds anyway (with blank input)
> 
>   - one reason we did not notice this immediately is that the failure
>     mode is to fall back to using the user's SSH_AUTH_SOCK variable if
>     set (i.e., their real agent with their keys in it!). We should
>     perhaps be clearing that variable in test-lib.sh.
> 
> But those are not really new issues, and I'm OK with just un-breaking
> things in the most expedient way possible.

Yeah. I was wondering whether we should rather do:

    ( ssh-agent -F || ssh-agent ) >env &&
    source env

ssh-agent(1) knows to detach into the background unless told otherwise,
so we should notice the failure and can then source the environment if
it was successful. But I ultimately decided that for now I'd rather want
to fix the fallout, we can still make it more robust after the fact.

> > An alternative approach would be to abbreviate the socket name itself so
> > that we create it as e.g. "sshsock" in the trash directory. But taking
> > the above example we'd still end up with a path that is 91 characters
> > long. So we wouldn't really have a lot of headroom, and it is quite
> > likely that some developers would see the issue on their machines.
> 
> I assume you mean here something like:
> 
>   ssh-agent "$PWD/sshsock"
> 
> Yeah, that is not buying us that much in terms of headroom. Plus it
> would still run afoul of the space issue, since we know that $PWD will
> always contain "trash directory".

Yup, that was the idea, and yeah, I don't think it helps us much.

> If we are going to provide a fixed name, I think it would have to be a
> true relative path like:
> 
>   ssh-agent ./sshsock
> 
> That does work (and SSH_AUTH_SOCK contains the relative path), but is
> maybe a bit of a booby trap waiting to spring on somebody who tries to
> access the agent with a different current working directory.

Maybe. On the other hand we only have a single test anyway that uses
ssh-agent, so that's a problem for the future, I guess.

In any case, I'd say for now we should just fix the issue in the easiest
way possible, and we can then follow up and make this more robust in a
subsequent patch series. WDYT?

Patrick