-
Notifications
You must be signed in to change notification settings - Fork 764
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Git server doesn't work with Win32-OpenSSH. Enclosed, please find three defects which I isolated and worked around.. #752
Comments
Thanks for the detailed report and proposed changes. Found some details here on how to setup Git server using over SSH - https://www.systutorials.com/366/set-up-git-server-through-ssh-connection/ |
Re: shell-host.c It appears that the whole nopty implementation assumes a pty control stream. Yet nopty may be a binary data stream. After removing the pty processing from: I can now clone repos over ssh and push changes to them. The whole send to child inner loop simplifies to:
|
What repo are you working on? There were changes around this logic as part of fixing #658 |
The repo is [email protected]:PowerShell/Win32-OpenSSH.git. Issue 1) from my initial post is still a problem. The file path sent by git contains literal single quote characters which become part of the file path, so the path is invalid. The remote repo in the following case is: localhost:D:\work\git_repo.git. Note the single quotes below. They may look like a double quote, but they are single quotes around single quotes. The inside single quotes are literals in the file path.
I also originally tried powershell.exe and bash.exe. None of the command line interpreters liked the literal single quotes when passed with the "/c" or "-c" option. cmd.exe works okay with double quotes, so I stopped looking for another solution to the problem. Regarding issue 2) of my original post: I do see quite a few changes, but the writes to pipe_out are still going back to the sshd process, not the child process child_pipe_write handle. Next, unless ssh options are mapped directly to cmd.exe options, I don't see how you can possibly detect any sub-mode of nopty, When the pipe is nopty, it's binary. A shell with tty capabilities would need to look at the binary stream and implement any tty escapes, not shell-host.c. Also, sshd.exe /ddd is still broken. |
I finally resolved another problem with large binary transfers, typical of a big git push. shell-host.c is currently using cmd.exe. cmd.exe was dropping the end of large binary streams over slow network connection. I tried bash.exe and powershell.exe as command interpreters and they do not drop any of the stream. It took quite a long time to discover that cmd.exe was the problem. I settled on using powershell.exe because it acts like cmd.exe for gitExtension file path resolution and resolves the common forms of path for Windows:
|
@razrjk as an FYI, we do code work out of https://github.com/PowerShell/openssh-portable, and only take drops back to this repo when we do releases. |
@razrjk please submit a PR on https://github.com/PowerShell/openssh-portable for the proposed changes. Also open a new issue for sshd.exe -ddd Also add details on where you installed Git for Windows from. |
To work around this issue, you can run the following commands in your local repository:
Replace After this you should be able to pull and push normally (works for me, anyway). Make sure you don't select "Use Git from Git Bash only" when installing Git on the Windows server, otherwise Git won't be in the PowerShell path. |
After further testing, I still get an error (early EOF) when pushing binary files. This is with v0.0.17.0. |
That's because it went through cmd to call powershell. I spent a day isolating the problem. My powershe'll bases ssh git server is working great!
Sent from Yahoo Mail on Android
On Wed, Jul 12, 2017 at 8:29 PM, Diogo Pereira<[email protected]> wrote:
After further testing, I still get an error (early EOF) when pushing binary files.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@razrjk, I start looking this. Could you please share more information so I can try it from end to end?
|
Above, I described three problems with the sshd nopty path (as of the date above - some of these problems may have been resolved. I have not pulled and rebuilt for a long time):
My Git repo paths take the form:
This supports efficient transfer between sites using Git compression over ssh, and yet the sshd server can use all the different types of Windows file path syntax. The double "//" in the path looks unusual, but it works. My systems are using Windows Active Directory and all accounts are domain accounts, validated by the Domain Controller. Interactive ssh/sshd work as well. |
@razrjk, my remote repo is setup at d:\testgit\myrepo.git on hostmachine. How do you specify the url for the path to your repo. I always see a '/' prefix at my URL. How do you remove it?
Here is the ssh log: |
Try You will probably continue to get the "does not appear to be a git repository" error after that, because of the way that If you want to try my workaround, you can do it this way: git init myrepo
cd myrepo
git remote add origin username@domain@hostmachine:D:/testgit/myrepo.git
git config --local remote.origin.uploadpack "powershell git upload-pack"
git fetch origin |
@diogocp how do you specify the port if you are not using the default 22? |
@bingbing8 I would set it in |
@diogocp, I don't repro the issues when pushing binary files (I use an executable file). I add the path to git-upload-pack to the system environment variable %Path% on host machine. Did you try on 0.0.20.0? |
Yes, I tried on 0.0.20.0. However, this does not happen with all binary files. @razrjk seems to think it is related to the size of the data ("cmd.exe does not work for large streamed data. The pipe breaks under heavy traffic load."). I have some doubts about this theory because:
You should be able to consistently reproduce it this way (at least I can): git clone https://github.com/PowerShell/Win32-OpenSSH.git
git init newrepo
cd Win32-OpenSSH
git remote add newrepo localhost:path/to/newrepo
git config --local remote.newrepo.receivepack "powershell git receive-pack"
git push newrepo |
Here is a simpler alternative. Try pushing this 28K file: https://repo.gradle.org/gradle/libs-releases-local/org/gradle/gradle-wrapper/4.1/gradle-wrapper-4.1.jar |
Diogo,
By "heavy traffic load" I mean large transfer over a weak internet connection. This is why it was difficult to isolate the problem. cmd.exe did not work, powershell.exe does. When you isolate the problem down to seeing that the pipe is breaking in cmd.exe for no apparent reason, then you will know.
Consider that you may have another problem if it is failing all the time.
|
@razrjk, thanks for the details issues reported and steps to help to identify the problems.
@diogocp I made some changes in shell-host.c. Please let me know if you still repro the big binary push issue after the fix. I posted a Setting up a Git server on Windows using Git for Windows and Win32_OpenSSH. please let me know if you see any other issue. |
Hi All, |
@HrochL , yes, it is a temporary workaround until we have a good fix on the server. |
@benvindo which step? this?
|
Move this issue to Beta until we have a proper fix on server |
@bingbing8 show me this error:
I tried add remote like this too: **When I put remote without slash in the start Do you have any idea what's causing this error? |
The cause of error above was I don't put environment 'git\mingw64\bin' in my variables env in server, however I got other error: |
There is no |
Hi, sorry for my lack of attention, I was focused on connecting the apps and forgetting the minimally details, Now its work perfectly. Thanks!! |
@diogocp, can you try the [latest release] (https://github.com/PowerShell/Win32-OpenSSH/releases/tag/v0.0.21.0) if you can repro early EOF error. |
@bingbing8 yes, same error with 0.0.21.0. |
@diogocp, I really can't repro it. what do you get in the client log? |
I have a similar error to @diogocp, at some point when a member of my team sends commits to a TFS repository and after some time we try to send all the commits to the production happens the error:
|
I follow your approach but I still get the |
@larry191994 you cannot use |
@larry191994 , @diogocp , after supporting default shell, you don't need the above workaround if you can set up Default Shell. Please refer to the link. |
TL;DR:
I'm sorry that I'm not commenting for this repo, but having the same problem hosting a Git repo's files on Windows 10 and want to work with them in another system through SSH. The problem looks the same as @bingbing8's
and @benvindo's
The URL is a trick to make the path to the repo valid. And we also have to alter/add configurations of Since we have Git installed on Windows 10 (or server...), we might have git-bash installed as well. And we can use Git's bash as the default bash for ssh, so that we can use git normally, without tweaking settings. The way to do so is to change the default shell for Windows 10's built-in openssh to git-bash, read TL;DR in the beginning. Then we should I don't really know how ssh works internally, but I just guess all these problems in this issue are so related to the host system's shell, openssh should not be blamed for and responsible for them. Probably, Git and Powershell can work together to get git working under powershell and/or even cmd. |
I come cross the above workaround and it solved the below issue in 2021.
|
I pulled version: 0.0.14.0 on May 19. I just fetched version: 0.0.15.0 (June 4) today to compare. I don't believe the below issues have been corrected.
Git using Win32-OpenSSH ssh server runs as a nopty service. There are two defects in the nopty code:
A temporary workaround for issue 1 is to replace all single quotes with double quotes just before the call to invoke cmd /c:
A fix for issue 2 is to use the child process file handle instead of the sshd file handle:
Finally, there is defect and debug issue in signal_sigchld.c. The zombied children count can become too large, which causes a seg fault. When debugging sshd.exe /ddd, debug3() is writing during signal processing which corrupts the stack. Debug3() should not write while running on an exception frame. A check for incorrect zombie count should be added:
I'm running on Windows 10 and Windows 7 systems.
Extreme care must be taken with search paths when debugging a git server using ssh protocol on Windows, especially if cygwin and mingw, etc., are also installed on the system This is true for the client and server side. Multiple executables for ssh, sshd, and git commands can cause problems if close attention is not paid to search paths.
The text was updated successfully, but these errors were encountered: