On Mon, 15 Jul 2024, mark.yagnatinsky@xxxxxxxxxxxx wrote: > Resending, got blocked last time. > > I have a few things I'd like to say about the (seriously nifty) connection sharing feature of OpenSSH and I'm not sure if the convention here is to use one email thread per distinct thing or just stuff everything into one email. > I decided to combine them because splitting is much easier than combining. > > Thing 1: This is the main thing that motivated me to write this email. > I'm on Windows 10 and I'm using the SSH client that comes bundled with Git for Windows, which I believe is basically the Cygwin port. (Or is it??) > I found bug 1278 in the issue tracker: https://bugzilla.mindrot.org/show_bug.cgi?id=1278 > It appears it has been fixed a few years ago, and the version I'm on is much newer than that, but it still doesn't work for me. It's been fixed in the sense that we added a way to do multiplexing on Cygwin (-O proxy), not fixed in the sense that Cygwin gained the file descriptor passing support needed to make the default way work. > Do you need more details to reproduce this or do you folks have a windows install to test this on? Try: ssh -oControlPath=/something -oControlMaster=yes -N you@host and open a multiplexed connection using: ssh -oControlPath=/something -O proxy you@host > Thing 2: It appears that "ssh -M localhost" does NOT attempt to start a "master" session, and the -M is silently ignored because no control path is mentioned. I'd think that this should be a fatal error, just like passing -S without giving a path. Instead, nothing is said, not even with -vvv. No, there is no default path. I can't remember whether -M without one not being fatal was intentional or not. Changing it now (after >20 years) does risk breaking working configurations. > Thing 3: Related to the previous point: is there any philosophical reason why there's no bundled default for the control path if none is given, or is this simply one of those things that no one ever got around to doing? > The analogous feature in PuTTY/plink (and also IntelliJ) Just Works, so coming from those clients this feels like ssh(1) needs micromanaging. This could be done, but see #2. Also Unix domain sockets are finicky wrt maximum path lengths and this can be a problem if the path is long, e.g. a user with a very long username (e.g. a GUID) connects to a host with a long hostname. > Thing 4: Are there any widespread conventions on where these socket files go, or does everyone pretty much do their own ad-hoc thing? The latter. Personally I mostly use ~/.ssh/ctl-%r@%h-%p-%C > Thing 5: Is there any way to tell the ssh client "try to connect using path/to/my-ctl.socket, and if it doesn't work, then exit with an error code"? -O proxy might do this incidentally, haven't tried. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
