ssh-agent creates $SSH_AUTH_SOCK within a temporary directory of the
form /tmp/ssh-XXXXXXXXXXXX.  These directories often stick around and
don't get cleaned up.  (Right now I have piles of them just from the
past month.) These directories seem like a perfect fit for /var/run,
rather than /tmp, since they exist primarily to provide a socket.
Moving them to /var/run should not break anything (since $SSH_AUTH_SOCK
would point to the new location), and should allow these directories to
get automatically cleaned up.  Furthermore, this reduces clutter in
/tmp.

Thanks,
Josh Triplett

retitle 620457 Please move /tmp/ssh-XXXXXXXXXXXX directories to $XDG_RUNTIME_DIR
unblock 620457 with 620458
thanks

A conversation with Michael Biebl turned up $XDG_RUNTIME_DIR, which
provides a much better fit than /var/run, not least of which because it
already has the appropriate permissions for users to create files in it.

- Josh Triplett

This was fixed upstream in 5.9.

Hello:

Please note that XDG_RUNTIME_DIR might be not set on some headless computers:
TMPDIR (and such) [see #619760] might be honour first instead.
Having said that, there exists packages that allows to clean up
the temporary directories (e.g., tmpreaper).

Jerome

Control: reopen 620457

No.  The upstream bug is CLOSED INVALID, with upstream arguing that
TMPDIR is sufficient but not replying to the objection raised against
that.

Removed 10s of /tmp/ssh-XXXXXXXXXXXX manually today.
My /tmp is a regular directory, not tmpfs, I guess it is the reason why i still suffer of this bug.
Regular systemd's cleanup of /tmp is enabled but these directories are explicitly excluded from it by /usr/lib/tmpfiles.d/openssh-client.conf
Maybe just remove it from the package?

https://salsa.debian.org/ssh-team/openssh/-/commit/015918425f1af02029f393ec1972de4d61f60a8d
describes why that tmpfiles.d entry is present.  I don't think any of
those reasons have changed, and so simply removing that entry would have
the consequences described in the first paragraph of that commit
message.