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

[Jeff King <peff@peff.net>]

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.

> 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".

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.

-Peff