I promised to be more patient and I think I'm doing better this time :) But I think I've waited long enough to be entitled to send a reminder now ;) So: does anyone know if -O proxy is documented anywhere official? Once I knew what to look for, I found the release notes for the version it was added, but I'd have never found that if I didn't already know the option name. In order to treat release notes as documentation for version N as documentation, you'd have to read all release notes from the start of time up to and including version N. Not very convenient. Oh, and it turns out that I decided to use -O check after all... else non-zero exit status is ambiguous: I can't tell if it failed because the control socket isn't there, or because it connected fine and then ran into trouble much later. -----Original Message----- From: Yagnatinsky, Mark : IT (NYK) Sent: Wednesday, July 17, 2024 7:40 AM To: Damien Miller <djm@xxxxxxxxxxx> Cc: openssh-unix-dev@xxxxxxxxxxx Subject: RE: scattered thoughts on connection sharing Thanks for replying! And noted, re: patience... will do. Passing -O proxy works!! This great! I feared I'd have to write an SSH client or something. You have improved my mood by at least 300%. I can't find this option documented ANYWHERE. Is it documented? Re: socket paths: thanks for the sample, I guess I'll use the .ssh dir too :) Re: thing 5: you're right it DOES do it incidentally :) mood improvement is now at least 350%. Thanks again, Mark P.S. THIS time I promise to be more patient before worrying about my email getting ignored. -----Original Message----- From: Damien Miller <djm@xxxxxxxxxxx> Sent: Tuesday, July 16, 2024 8:47 PM To: Yagnatinsky, Mark : IT (NYK) <mark.yagnatinsky@xxxxxxxxxxxx> Cc: openssh-unix-dev@xxxxxxxxxxx Subject: Re: scattered thoughts on connection sharing CAUTION: This email originated from outside our organisation - djm@xxxxxxxxxxx Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. 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://clicktime.symantec.com/15siFCkSVRsqDr49GcfVg?h=Ag_oFPlSxrwZtwW > FcpAWZZvtWhx50PyQjVe572dkDKA=&u=https://bugzilla.mindrot.org/show_bug. > cgi?id%3D1278 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 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
