[Image] The `socat` "proxying" of SSH_AUTH_SOCK hangs intermittently on macOS

[mattijv]

Version of Warden

0.15.0

Operating System and Installation Method

macOS 15.6.1 via Brew

Image

php-fpm:8.2-magento2

Describe the Bug

I ran into the exact same issue as #331 while setting our Warden environments up on a new computer.

I was trying to run a composer install that clones a lot of private repositories, and it kept hanging during git operations. I finally narrowed the issue to the exact same problem described in #331: the socat "proxying" of the SSH_AUTH_SOCK sometimes hangs, with the same error.

It was easy to replicate (as described in the previous issue) by spamming ssh-add -L several times in succession.

The issue is intermittent but constant. I haven't been able to run a full composer install without it hanging at some point.

Running

sudo chown www-data:www-data /run/host-services/ssh-auth.sock
export SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock
composer install

made the install complete successfully, so I think that rules out any issues with the ssh-agent forwarding itself.

To Reproduce

1. Repeatedly run ssh-add -L (sometimes a couple times is enough, sometimes takes a few tens of tries).

Expected Behavior

Forwarded identities are shown correctly every time the ssh-add -L is ran.

Additional context

strace of ssh-add -L shows it hanging on read() on the socket file:

[...]
read(3, "d look\n# For type CA, the listed"..., 4096) = 4096
read(3, "ltName=email:copy\n# Copy issuer "..., 4096) = 4096
read(3, "dcert = $insta::certout # insta."..., 4096) = 124
read(3, "", 4096)                       = 0
close(3)                                = 0
futex(0xffffa3ec2540, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0xffffa3ec255c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0xffffa3ec2d3c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0xffffa3ec2e54, FUTEX_WAKE_PRIVATE, 2147483647) = 0
getpid()                                = 4355
brk(0xaaaae9fd5000)                     = 0xaaaae9fd5000
getrandom([snip]..., 48, 0) = 48
getpid()                                = 4355
getpid()                                = 4355
getpid()                                = 4355
getpid()                                = 4355
getpid()                                = 4355
socket(AF_UNIX, SOCK_STREAM, 0)         = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
connect(3, {sa_family=AF_UNIX, sun_path="/tmp/ssh-auth.sock"}, 110) = 0
write(3, "\0\0\0\1", 4)                 = 4
write(3, "\v", 1)                       = 1
read(3,

Running socat with the -v and -x handles reveals this in the logs:

< 2025/09/12 11:18:29.021870  length=5 from=0 to=4
 00 00 00 01 0b                                   .....
--
> 2025/09/12 11:18:29.022980  length=447 from=0 to=446
 00 00 01 bb 0c 00 00 00 01 00 00 01 97 00 00 00  ................
 [...redacted ssh key]
--
< 2025/09/12 11:18:29.786366  length=5 from=0 to=4
 00 00 00 01 0b                                   .....
--
> 2025/09/12 11:18:29.787632  length=447 from=0 to=446
 00 00 01 bb 0c 00 00 00 01 00 00 01 97 00 00 00  ................
 [...redacted ssh key]
--
< 2025/09/12 11:18:30.158996  length=5 from=0 to=4
 00 00 00 01 0b                                   .....
--
> 2025/09/12 11:18:30.160553  length=447 from=0 to=446
 00 00 01 bb 0c 00 00 00 01 00 00 01 97 00 00 00  ................
 [...redacted ssh key]
--
< 2025/09/12 11:18:30.632343  length=5 from=0 to=4
 00 00 00 01 0b                                   .....
--
> 2025/09/12 11:18:30.633129  length=447 from=447 to=893
 00 00 01 bb 0c 00 00 00 01 00 00 01 97 00 00 00  ................
 [...redacted ssh key]
--
2025/09/12 11:18:30 socat[358] E write(7, 0xaaaae2e8e000, 447): Broken pipe

The first few exchanges work correctly but the last one breaks. The data is always the SSH key, but in the last one the from and to are different. As if socat was trying to write to the previous connection..?

[mattijv]

Fixing the actual issue with socat is out-of-scope for the repository, but this seems "common" enough of an issue that it's worth to write up.

I'm looking into solving this by using the /run/host-services/ssh-auth.sock directly by chowning it to the www-data user in the docker-entrypoint script, but I'm not sure if that has some undesirable side-effects...