scattered thoughts on connection sharing

[Damien Miller]

On Mon, 15 Jul 2024, mark.yagnatinsky at barclays.com 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 at host

and open a multiplexed connection using:

ssh -oControlPath=/something -O proxy you at 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