"Could not read from remote repository" with git+openssh

[OhSoGood]

Hi,

Still switching from other ssh daemon to OpenSSH-Win64 (using Dec 22, 2015 version), I'm facing a "Could not read from remote repository" error with git when using a git url like this:
ssh://myusername@myhost:1234/GitRepos/MyRepoName

The exact error in git (when doing a pull for instance) is:

fatal: ''/GitRepos/MyRepoName' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Of course, the path exists and is even readable by everybody, and the git URL works well if I use another SSH daemon (ex: copssh)

Here is the log of openssh:

2292 23:38:56 711 Starting session: command for cruisecontrol from 192.168.1.65 port 41796
2292 23:38:56 711 debug1: allocating new sfd, sfd [5] fd [5] handle [420] type [2]
2292 23:38:56 711 debug1: allocating new sfd, sfd [6] fd [6] handle [424] type [2]
2292 23:38:56 711 debug1: allocating new sfd, sfd [7] fd [7] handle [428] type [2]
2292 23:38:56 711 debug1: allocating new sfd, sfd [8] fd [8] handle [432] type [2]
2292 23:38:56 711 debug1: allocating new sfd, sfd [9] fd [9] handle [436] type [2]
2292 23:38:56 711 debug1: allocating new sfd, sfd [10] fd [10] handle [440] type [2]
2292 23:38:56 711 debug1: Using token from lsa...
2292 23:38:56 711 debug1: Executing command: git-upload-pack '/GitRepos/MyRepoName'
2292 23:38:56 727 debug1: read from socket sfd [8] failed with error code [10054]
2292 23:38:56 727 debug1: read from socket sfd [10] failed with error code [10054]
2292 23:38:56 727 debug1: Received SIGCHLD.
2292 23:38:56 727 debug1: session_by_pid: pid 452
2292 23:38:56 727 debug1: session_exit_message: session 0 channel 0 pid 452
2292 23:38:56 727 debug1: session_exit_message: release channel 0
2292 23:38:56 727 debug1: read from socket sfd [3] failed with error code [10035]
2292 23:38:56 773 debug1: session_by_channel: session 0 channel 0
2292 23:38:56 773 debug1: session_close_by_channel: channel 0 child 0
2292 23:38:56 773 debug1: session_close: session 0 pid 0
2292 23:38:56 773 debug1: channel 0: free: server-session, nchannels 1

Any idea? It could be close to #43 but that didn't help me.

Thanks for your help!

[manojampalam]

Not sure. What does git-upload-pack do and how does it work? Does it need authentication?

[OhSoGood]

As per git documentation, it's part of a normal 'git fetch' (
https://www.kernel.org/pub/software/scm/git/docs/git-upload-pack.html ) ,
more precisely:

Invoked by git fetch-pack, learns what objects the other side is missing,
and sends them after packing.

This command is usually not invoked directly by the end user. The UI for
the protocol is on the git fetch-pack side, and

the program pair is meant to be used to pull updates from a remote
repository. For push operations, see git send-pack.

[OhSoGood]

I wonder if the following article could not be a explanation: http://blog.chronosinteractive.com/posts/using-windows-server-host-git-repository . With another ssh server (bitvise):

Set "Exec request prefix" to cmd.exe /c sh gitcmdhelper.sh (last character must be a space)
Explanation of gitcmdhelper.sh
The gitcmdhelper.sh file is key to getting this process working. The $* in this file is a string of all the > arguments passed to the function. The git-upload-pack and git-receive-pack utilities that Git runs
during clone, fetch, and push requests uses single quotes to enclose the path of the repository.
Windows doesn't like this. The $* strips these single quotes away. (One side-effect of this is that
your repository path cannot contain any spaces.)

Indeed, in the error msg in 1st post, I had: Executing command: git-upload-pack '/GitRepos/MyRepoName'
Could that be the quotes for you? If so, how can we apply the same trick with OpenSSH (I didn't see any 'Exec request prefix' param in OpenSSH.

[diogocp]

See #752. You can solve the single quotes problem by changing the receivepack command, but even after that Git still doesn't work properly.

[manojampalam]

All Git related issues are being in #752