scp.exe not working when receiving files over Windows OpenSSH Server (lost connection)

[mbrde]

Hi,

my Setup:
Windows server 2022
Git for Windows 2.43.0
OpenSSH Server => Default Shell: Git Bash

SSH works fine. Now the Problem:

I want to send a file over scp to the Windows Server, for example: local test.txt to C:\temp\test.txt

Expected command: scp test.txt Administrator@srv-test:/c/temp/ => not working, error lost connection, details later.

If I change default shell to powershell, the remote path is /C:/test => this works

Back to default shell git bash. I remove scp.exe from git /usr/bin and use the remote path /C:/test => this works

Let's check debugging and call scp with -vvv:

When comparing both outputs (working and not working), there are some differences:

working:

debug1: Sending command: scp -v -t C:/temp/
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
Sending file modes: C0664 1314 test.txt
debug2: channel 0: rcvd ext data 1
Sdebug2: channel 0: written 1 to efd 6
debug2: channel 0: rcvd ext data 27
ink: C0664 1314 test.txt
debug2: channel 0: written 27 to efd 6
test.txt 100% 1314 1.1MB/s 00:00
debug2: channel 0: read<=0 rfd 4 len 0
debug2: channel 0: read failed
debug2: channel 0: chan_shutdown_read (i0 o0 sock -1 wfd 4 efd 6 [write])
debug2: channel 0: input open -> drain
debug2: channel 0: ibuf empty
debug2: channel 0: send eof
debug3: send packet: type 96
debug2: channel 0: input drain -> closed
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: chan_shutdown_write (i3 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed

not working:

debug1: Sending command: scp -v -t /c/temp
debug2: channel 0: request exec confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
Sending file modes: C0664 1314 test.txt
debug3: receive packet: type 96
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: chan_shutdown_write (i0 o1 sock -1 wfd 5 efd 6 [write])
debug2: channel 0: output drain -> closed
lost connection

It seems that the remote scp.exe cannot handle the file or the path.

[dscho]

It seems that the remote scp.exe cannot handle the file or the path.

That sounds plausible, as /c/temp is not a valid Windows path (or at least not the valid Windows path you want to use, C:/temp). So it strikes me as yet another instance of the path conversion problem. From our Release Notes' "Known Issues" section:

• If you specify command-line options starting with a slash, POSIX-to-Windows path conversion will kick in converting e.g. "/usr/bin/bash.exe" to "C:\Program Files\Git\usr\bin\bash.exe". When that is not desired -- e.g. "--upload-pack=/opt/git/bin/git-upload-pack" or "-L/regex/" -- you need to set the environment variable MSYS_NO_PATHCONV temporarily, like so:

MSYS_NO_PATHCONV=1 git blame -L/pathconv/ msys2_path_conv.cc

Alternatively, you can double the first slash to avoid POSIX-to-Windows path conversion, e.g. "//usr/bin/bash.exe".

In your instance, the alternative won't work, but MSYS_NO_PATHCONV=1 should work.

[mbrde]

None of the alternatives work, also MSYS_NO_PATHCONV makes no difference.
Only scp over ssh is a problem. scp.exe can handle all path variants if you run it locally.