bugzilla-daemon at mindrot.org
2023-Dec-25 21:20 UTC
[Bug 3648] New: ssh client blocks itself by leaving unix domain socket alive after user
https://bugzilla.mindrot.org/show_bug.cgi?id=3648 Bug ID: 3648 Summary: ssh client blocks itself by leaving unix domain socket alive after user Product: Portable OpenSSH Version: 9.3p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org Reporter: hadmut at danisch.de Hi, I'm using Ubuntu Linux (client 23.10, server 22.04) and want to use port forwarding to connect a unix domain socket from client do server. When using something like LocalForward /tmp/TEST /tmp/TEST it works as expected. For testing, run nc -v -l -U /tmp/TEST on the server and then curl -D /dev/stdout --unix-socket /tmp/TEST http://xyz/ or nc -U /tmp/TEST on the client side to see, that it is working fine. :-) But then, it is working only for one session. Not for subsequent sessions, because ssh opens /tmp/TEST on the client side (I guess the same for RemoteForward on the server, but haven't tested yet), and leaves the socket /tmp/TEST existing, but can't reuse it. For the ext run, ssh issues unix_listener: cannot bind to path /tmp/TEST: Address already in use and can't use it, thus the connection does not work anymore. It requires a rm /tmp/TEST after every single ssh call, which is annoying and error prone. If ssh creates a unix domain socket, it should delete it when terminating (or be able to reuse it / use an existing socket). regards -- You are receiving this mail because: You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2024-Mar-07 10:27 UTC
[Bug 3648] ssh client blocks itself by leaving unix domain socket alive after user
https://bugzilla.mindrot.org/show_bug.cgi?id=3648 --- Comment #1 from Hadmut Danisch <hadmut at danisch.de> --- Any response? -- You are receiving this mail because: You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2024-Mar-07 18:39 UTC
[Bug 3648] ssh client blocks itself by leaving unix domain socket alive after user
https://bugzilla.mindrot.org/show_bug.cgi?id=3648 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djm at mindrot.org --- Comment #2 from Damien Miller <djm at mindrot.org> --- Does the StreamLocalBindUnlink do what you want? -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2024-Mar-09 23:12 UTC
[Bug 3648] ssh client blocks itself by leaving unix domain socket alive after user
https://bugzilla.mindrot.org/show_bug.cgi?id=3648 --- Comment #3 from Hadmut Danisch <hadmut at danisch.de> --- Apparently, yes, partly, thanks. It seems to work for LocalForward, but not for RemoteForward. The option exists in the sshd_config man page, so I guess this must be set on the server side as well in order to make it work for RemoteForward, but that doesn't help in that particular use case, since users do not have admin rights on the remote machine. Didn't see that option, and I do know about other long-time-experienced admins with the same problem, who didn't see this either. Maybe a hint in the LocalForward and RemoteForward sections of man page for ssh_config would be useful. But what sense does it make to leave the socket in the filesystem, if ssh will never ever again be able to reuse it, it just keeps ssh from working again? What's that good for? I'd see two modes of operation: - either leave the socket intact, but be able to reuse it with subsequent ssh sessions, which might make sense for other client programs using it, - or remove it and create a new one for every ssh connection. but the current default mode of ssh does not seem to be working and thus not seem to make sense. (BTW: Did you see my e-mail to the mailing list about XDG_RUNTIME_DIR environment variable on the server side?) regards -- You are receiving this mail because: You are watching someone on the CC list of the bug. You are watching the assignee of the bug.