scattered thoughts on connection sharing

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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.
Do you need more details to reproduce this or do you folks have a windows install to test this on?

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.

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.

Thing 4: Are there any widespread conventions on where these socket files go, or does everyone pretty much do their own ad-hoc thing?

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"?
I originally had a long rant written here how -O check is not suitable because it has a TOCTOU issue.
Namely, the persist timeout could expire after the check but before trying to connect.
But it turns out that merely checking resets the timer, so this is not likely to be an issue in practice after all.
I still wish I didn't have to use it because it means I have to launch an extra process, which is very slow on our laptops for some reason.
(Only for Cygwin-ish things. native windows processes launch quickly)


There might have been a Thing 6 but if so I can't recall it right this moment, so.

That's all for now,
Mark.
This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.ib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: https://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.ib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev




[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux