With this in my .ssh/config: ControlMaster auto ControlPath ~/.ssh/master-%r@%h-%p I do (in one shell) ssh -Mnf REMOTE.HOST.NAME sleep 600 <enter password> In other shell ssh REMOTE.HOST.NAME Master says: mm_receive_fd: no message header - - and exits "Slave" says: ssh_msg_recv: read: header control_client: msg_recv - - and exits Tried various permutations with -M, -S and nothing in config file, yield same result.
Created attachment 1234 [details] -v -v -v log of the initial master during failure ssh -Mnf -v -v -v -S .ssh/foo REMOTE.HOST.NAME sleep 600 2> ssh.log (hostnames and ips removed from log)
Created attachment 1235 [details] log of client connection during failure ssh -v -v -v -S .ssh/foo REMOTE.HOST.NAME 2> sshclient.log (hostnames and ips removed)
ControlMaster works by passing a file descriptor between unrelated processes via a Unix domain socket, and I don't think that's even possible on Cygwin. ssh should probably return a more specific error message if that's the case.
I am not at all a cygwin expert, but it seems from googling that there is support for unix domain sockets: see http://comments.gmane.org/gmane.os.cygwin/1046, for example. I'll see if I can put together a python testcase demonstrating cygwin unix domain sockets work. Note that in the example I wsa running I did see ssh -M creating "something" in the file system. Here's what happens when I do ssh -M -S /tmp/foo3 some.hostname... ls -l /tmp srw------- 1 mgreenberg None 53 Jan 29 18:05 foo3
(In reply to comment #4) > I am not at all a cygwin expert, but it seems from googling that there > is support for unix domain sockets: [...] It's not Unix domain sockets that's the problem but *descriptor passing over Unix domain sockets*. I found the reference I was thinking of from Corinna (who most definitely is a Cygwin expert :-) here: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=108357562706575 The fact that Cygwin in general works as well as it does makes it easy to forget that the underlying OS is actually quite difference.
so sad. I was really looking forward to this feature...
OpenSSH can't do anything to resolve this, it is a limitation of the Cygwin platform libraries. If Cygwin is able to make fd passing work on Windows, then OpenSSH will automatically work. I'll close this bug, because there is nothing we can do here.
Close resolved bugs after release.
Couldn't OpenSSH automatically use a different method for an OS which doesn't support domain sockets (or their passing)? E.g. OpenSSH could use normal sockets. It could open a socket on a free TCP/IP port and write the port and a passkey into the control-master file. The second ssh could connect to the first ssh using this socket. This would allow to use this feature independent of the OS.
During last months I devoted some time to solve this problem. In cooperation with Cygwin maintainer I build ssh client for cygwin, which is able to connect to server using multiplexed connection. It was briefly tested in scap-workbench for windows [1] and success was reported. It is really unlike that file descriptors passing will be implemented in cygwin in near future (not sure if windows is even able to do this somehow) so we have chosen to make workaround in openssh using unix domain sockets. Unfortunately, it is not full featured solution and it doesn't handle full featured pseudo terminals. It is targeted more to remote command execution, file uploads and file downloads, which is more common use case for automation and works fine. So enough of words, here is the current version of patch [2]. I'm posting it here to see if upstream is interested in this feature, otherwise it will have to be maintained as downstream cygwin patch. And of course, comments, improvements and patches are welcomed. [1] https://github.com/OpenSCAP/scap-workbench/issues/14#issuecomment-120105262 [2] https://github.com/Jakuje/stuff/blob/master/openssh_without_fdpass.patch
FYI Markus is working on a way to run the ssh protocol over a Unix domain socket between mux server and client, based on a discussion with Simon Tatham about how PuTTY does it. That would remove the dependency on Unix descriptor passing and allow it to work on Cygwin.
The change I mentioned in comment #11 bas been committed: https://anongit.mindrot.org/openssh.git/commit/?id=8d0578478586e283e751ca51e7b0690631da139a This should allow multiplexing to work on Cygwin since it does not rely on descriptor passing (I do not currently have access to a system to test it, though).
Remove this from the 7.4 release blockers list. We have at least the beginnings of a solution for 7.4 in place now (in the form of mux proxy mode)
Darren's last message indicated that this is probably fixed, please reopen if this isn't the case.
closing resolved bugs as of 8.6p1 release