Feature request: File descriptor support by sockets.

Feature request: File descriptor support by sockets.

[Darren Whobrey]

[-- Attachment #1: Type: text/plain, Size: 4054 bytes --]

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<mailto: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.

Re: Feature request: File descriptor support by sockets.

[Adam Dinwoodie]

On Thu, 6 Oct 2022 at 18:37, Darren Whobrey wrote:
>
> 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":
>
> <snip>
>
> When successful connections are made from an OL7 client (with older version of OpenSSH, but mux commands are similar), comparative logs are:
>
> <snip>
>
> 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?

I'm very confident it *can* be fixed! But this gap has existed since
at least 2009 (see
https://cygwin.com/pipermail/cygwin/2012-February/199995.html and
https://sourceware.org/legacy-ml/cygwin/2009-10/msg00397.html) so I
suspect that, unless you're proposing to do the work or pay someone to
do it on your behalf, it's unlikely to happen any time soon.