fatal: protocol error: bad line length character:

问题:

I have a Windows 2008 R2 Server Standard Edition. I have FreeSSHd installed along with Git. Windows firewall has exceptions set to port 22. I have the SSH server setup to accept only SSH public keys. I can login to the server fine using terminal (i.e. ssh gregory@hostname). When I go to use the git clone command (e.g. git clone ssh://gregory@hostname/path_to_my_repo) I get this error:

fatal: protocol error: bad line length character: Unab

I am at an absolute loss as to what's causing it. I have Shell, SFTP and Tunnel protocols enabled.

回答1:

Forget freeSSHd. It cannot be configured to run with git.

You have two (as far as I could find) choices - go with a more sophisticated SSH server for Windows and then implement this: http://holyhoehle.wordpress.com/2011/01/26/setting-up-a-git-server-on-windows-server-2008-r2-using-msysgit-and-winsshd/

or go with OpenSSH (CopSSH)

http://java2cs2.blogspot.de/2010/03/setup-git-server-on-windows-machine.html

http://www.timdavis.com.au/git/setting-up-a-msysgit-server-with-copssh-on-windows/

Setup a Git server with msysgit on Windows

http://code.google.com/p/tortoisegit/wiki/HOWTO_CentralServerWindowsXP

回答2:

Git over SSH uses the output of the SSH pipe verbatim. If that output contains any spurious data not related to git, then the git command fails to parse that and aborts with an obscure error message. That can happen if you have a user script that displays stuff when you connect, for instance, or if something throws an error message not understood by git.

You'll note that 'Unab' looks like the beginning of 'Unable', presumably an error message meant for a human being, not git, indeed.

What happens when you run the following command?

ssh gregory@hostname git-upload-pack '/path_to_your_repo'

In theory you should get an error message starting with 'Unable'. For instance, 'Unable to find git-upload-pack'. In which case the fix will be to add git-upload-pack to your path!

回答3:

I had the same problem today at my job... so I found this: Setting up a Git Server on Windows Server 2008 R2

What you need to see is below:

Making Git work on the server:

1. If not already done, install msysgit on your server (I would recommend to install it directly to C:\Git or at least a path that has no spaces because I had some weird issues with “spaced” paths)

2. Add C:\Git\bin to the PATH variable. This is very important!! sh.exe and other dependencies are in this folder

3. Now go to C:\Git\bin and add the following two files

gup.sh grp.sh 4. Open gup.sh in your favorite editor and insert

C:/Git/libexec/git-core/git-upload-pack.exe $* 5. Open grp.sh and insert

C:/Git/libexec/git-core/git-receive-pack.exe $* The $* essentially rips off the single quotes from the repository path argument, so a path that has spaces in it won’t work here either I guess

Basically we’re done now and all git operations from the client should work. For a clone you have to type

git clone -u 'sh gup.sh' ssh://username@server/path/to/myrepo.git or a push would be

git push --exec 'sh grp.sh' ssh://username@server/path/to/myrepo.git but that is not very elegant.

Cleaning things up:

1. At first we want to get rid of the whole repo path by specifying a remote alias

git remote add origin ssh://username@server/path/to/myrepo.git Where “origin” would be the alias name

1. Next we set the config for the git-upload-pack and git-receive-pack so we don’t have to reference the shell script all the time.

git config remote.origin.uploadpack 'sh gup.sh' and

git config remote.origin.receivepack 'sh grp.sh' That’s it. Now we can use the normal git commands without any additional parameters:

git clone origin git push origin master git pull origin ...

回答4:

In my case, I had an

echo $HOSTNAME

in my .bashrc and .bash_profile that I was using to diagnose some connection problems. This gave me the message:

fatal: protocol error: bad line length character: [VSR 

when I tried to git pull from an ssh repo. Removing the echo statements makes things work; the '[VSR' is just the first 4 characters from the echo.