Hi, I'm using the latest version of Cygwin (3.3.6) and the Cygwin OpenSSH (OpenSSH_9.0p1, OpenSSL 1.1.1q 5 Jul 2022) version of ssh to talk to hosts using ControlMaster connection sharing. This uses sockets behind the scenes. When ControlMaster is set to no, the connection is successful. Ssh connections are failing at the point where IO starts to be forwarded to the host. Here's a snippet of log output from "ssh -vvv some-host": debug3: mux_master_read_cb: channel 1: hello sent debug3: mux_master_read_cb: channel 1 packet type 0x00000001 len 4 debug2: mux_master_process_hello: channel 1 client version 4 debug2: mux_client_hello_exchange: master version 4 debug3: mux_client_request_stdio_fwd: entering debug3: mux_client_request_alive: entering debug3: mux_master_read_cb: channel 1 packet type 0x10000004 len 4 debug2: mux_master_process_alive_check: channel 1: alive check debug3: mux_client_request_alive: done pid = 389 debug3: mux_client_request_stdio_fwd: stdio forward request sent debug3: mux_master_read_cb: channel 1 packet type 0x10000008 len 53 debug2: mux_master_process_stdio_fwd: channel 1: stdio fwd to some-host:22 mm_receive_fd: no message header mux_master_process_stdio_fwd: failed to receive fd 0 from client debug1: channel 1: mux_rcb failed debug2: channel 1: zombie debug2: channel 1: gc: notify user debug3: mux_master_control_cleanup_cb: entering for channel 1 debug2: channel 1: gc: user detached debug2: channel 1: zombie debug2: channel 1: garbage collecting debug1: channel 1: free: mux-control, nchannels 2 debug3: channel 1: status: The following connections are open: mux_client_request_stdio_fwd: read from master failed: Connection reset by peer kex_exchange_identification: Connection closed by remote host Connection closed by UNKNOWN port 65535 When successful connections are made from an OL7 client (with older version of OpenSSH, but mux commands are similar), comparative logs are: debug3: mux_master_read_cb: channel 1: hello sent debug3: mux_master_read_cb: channel 1 packet type 0x00000001 len 4 debug2: process_mux_master_hello: channel 1 slave version 4 debug2: mux_client_hello_exchange: master version 4 debug3: mux_client_request_stdio_fwd: entering debug3: mux_client_request_alive: entering debug3: mux_master_read_cb: channel 1 packet type 0x10000004 len 4 debug2: process_mux_alive_check: channel 1: alive check debug3: mux_client_request_alive: done pid = 27228 debug3: mux_client_request_stdio_fwd: stdio forward request sent debug3: mux_master_read_cb: channel 1 packet type 0x10000008 len 53 debug2: process_mux_stdio_fwd: channel 1: request stdio fwd to some-host:22 debug3: process_mux_stdio_fwd: got fds stdin 7, stdout 8 debug2: fd 7 setting O_NONBLOCK debug2: fd 8 setting O_NONBLOCK debug1: channel_connect_stdio_fwd some-host:22 debug1: channel 2: new [stdio-forward] debug3: fd 7 is O_NONBLOCK debug3: fd 8 is O_NONBLOCK debug1: getpeername failed: Bad file descriptor debug3: send packet: type 90 debug2: process_mux_stdio_fwd: channel_new: 2 linked to control channel 1 debug3: receive packet: type 80 debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug3: receive packet: type 91 debug2: callback start debug3: mux_stdio_confirm: sending success reply debug2: callback done debug2: channel 2: open confirm rwindow 2097152 rmax 32768 debug1: mux_client_request_stdio_fwd: master session id: 2 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4 debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000 debug2: fd 5 setting O_NONBLOCK debug2: fd 4 setting O_NONBLOCK debug1: Authenticating to some-host:22 as 'myusername' According to this web posting, it suggests the bug lies with "file descriptors over unix sockets do not work in Cygwin": https://exchangetuts.com/is-ssh-controlmaster-with-cygwin-on-windows-actually-possible-1639696447917488 Is this something that can be fixed? Regards, Darren.