git protocol on windows
Lee Henson
Firstly: epic work here chaps. Bravo to all concerned.
Secondly: I'm happily using msysgit as a 'client' to an origin
repository on github, pushing and pulling with ssh through pageant.
I'm wondering now if it is at all possible to reproduce this
arrangement on a windows box? I've installed freeSSHd and created a
simple test repository called (imaginatively) "Test" on a Windows
Server 2003 box. However I'm struggling to determine the correct uri
for my "git clone" on my client pc. No matter what I try I get a
network timeout. I guess there are protocol issues here - the server
presumably doesn't know how to respond to a git+ssh request? Any
suggestions?
Cheers
Lee
Johannes Schindelin
On Tue, 26 Feb 2008, Lee Henson wrote:
> I'm happily using msysgit as a 'client' to an origin repository on
> github, pushing and pulling with ssh through pageant.
>
> I'm wondering now if it is at all possible to reproduce this arrangement
> on a windows box? I've installed freeSSHd and created a simple test
> repository called (imaginatively) "Test" on a Windows Server 2003 box.
>
> However I'm struggling to determine the correct uri for my "git clone"
> on my client pc. No matter what I try I get a network timeout. I guess
> there are protocol issues here - the server presumably doesn't know how
> to respond to a git+ssh request? Any suggestions?
My guess is that freeSSHd does not come with a login shell that
understands git's remote command line, or that the login shell is
interactive-only (and maybe not even finding git-upload-pack.exe).
Why not just set up a git daemon? Yes, it is not authenticated, but you
are not using a Window2003 server with a public IP, do you?
Ciao,
Dscho
Lee Henson
-----
Hi
Comments in line:
My guess is that freeSSHd does not come with a login shell that
understands git's remote command line, or that the login shell is
interactive-only (and maybe not even finding git-upload-pack.exe).
Apologies for my ignorance as I don't have a great deal of experience with ssh servers! You can specify a command shell which is presently set to c:\windows\system32\cmd.exe, but should this be pointing at the c:\program files\git\bin\git.exe? Further configuration info:
- Password authentication is disabled
- Public key authentication is enabled
- Listening on port 22 on all interfaces
Why not just set up a git daemon? Yes, it is not authenticated, but you
are not using a Window2003 server with a public IP, do you?
Actually yes, it is publicly accessible as we would like to be able to pull/push from offsite locations. Therefore unauthenticated access, even readonly, is not an option.
Many thanks for your help.
L
Johannes Schindelin
On Wed, 27 Feb 2008, Lee Henson wrote:
> Comments in line:
>
> On 27/02/2008, Johannes Schindelin <Johannes....@gmx.de> wrote:
> >
> >
> > My guess is that freeSSHd does not come with a login shell that
> > understands git's remote command line, or that the login shell is
> > interactive-only (and maybe not even finding git-upload-pack.exe).
>
>
> Apologies for my ignorance as I don't have a great deal of experience
> with ssh servers! You can specify a command shell which is presently set
> to c:\windows\system32\cmd.exe, but should this be pointing at the
> c:\program files\git\bin\git.exe?
No, if at all, it should be pointing to bash.exe.
But it could be possible that just adding Git's bin/ to the system PATH is
enough; however, you will not be able to access anything except the C:
drive, then, I believe.
> Further configuration info:
>
> - Password authentication is disabled
> - Public key authentication is enabled
> - Listening on port 22 on all interfaces
>
> > Why not just set up a git daemon? Yes, it is not authenticated, but
> > you are not using a Window2003 server with a public IP, do you?
>
> Actually yes, it is publicly accessible as we would like to be able to
> pull/push from offsite locations.
And you trust Windows to do the job? Courageous!
> Therefore unauthenticated access, even readonly, is not an option.
Right.
Ciao,
Dscho
Lee Henson
No, if at all, it should be pointing to bash.exe.
But it could be possible that just adding Git's bin/ to the system PATH is
enough; however, you will not be able to access anything except the C:
drive, then, I believe.
Ok, so I've pointed it at bash.exe. I'm not sure I want to add bin to the path on the server, so I have left that out.
My biggest mental block about this at the moment is how a command like "git clone git://hostname/git/test.git" on the client would be translated to git on the server interacting with c:\git\test. Questions:
- Presumably the clone command knows that a uri with a "git" protocol should be sent via ssh? If so, that's great, if not should I be using uris of the form git+ssh://<hostname>/path?
- Assuming an ssh request has been received on the server and successfully authenticated against the public/private keys, how does it know which folder on the server to look in? E.g. will git://<hostname>/git/test.git look in c:\git\test? Is there something I should be putting in gitconfig to say "this is where my repositories are kept"?
And you trust Windows to do the job? Courageous!
Lol. Sometimes we just have to work with tools we've got....
Actually, the main reason I want to have everything running on windows is so we can (easily) use it as part of a continuous integration strategy (at some point). I am assuming (possibly dangerously) that either the post-commit hooks work at the moment or that they are expected to be working at some point in the future.
Many thanks!
Lee
Johannes Schindelin
On Wed, 27 Feb 2008, Lee Henson wrote:
> On 27/02/2008, Johannes Schindelin <Johannes....@gmx.de> wrote:
>
> > No, if at all, it should be pointing to bash.exe.
> >
> > But it could be possible that just adding Git's bin/ to the system
> > PATH is enough; however, you will not be able to access anything
> > except the C: drive, then, I believe.
>
> Ok, so I've pointed it at bash.exe. I'm not sure I want to add bin to
> the path on the server, so I have left that out.
By pointing to c:\Program Files\Git\bin\bash.exe, you _implicitly_ have it
in the PATH, but only for that process.
> My biggest mental block about this at the moment is how a command like
> "git clone git://hostname/git/test.git" on the client would be
> translated to git on the server interacting with c:\git\test.
It is not. git:// protocol would need the git-daemon, as I suggested
earlier. With ssh, you have to say "ssh://hostname/c/that-repository/".
And to prevent a common misconception: you should set up a bare repository
if you plan to push into it.
It probably would not hurt to read the relevant sections in the Git User
Manual, too...
> - Presumably the clone command knows that a uri with a "git" protocol should
> be sent via ssh? If so, that's great, if not should I be using uris of the
> form git+ssh://<hostname>/path?
The latter.
> - Assuming an ssh request has been received on the server and successfully
> authenticated against the public/private keys, how does it know which folder
> on the server to look in? E.g. will git://<hostname>/git/test.git look in
> c:\git\test?
No, if you leave out the drive letter, it will be relative to the Git
root, in your case C:\Program Files\Git.
> I am assuming (possibly dangerously) that either the post-commit hooks
> work at the moment or that they are expected to be working at some point
> in the future.
Somehow I got a feeling that this was a pretty disguised question. To
answer it: post-commit hooks work. You just have to enable them. In
msysGit, you do that by renaming the hook from "post-commit-disabled" to
"post-commit".
Hth,
Dscho
Lee Henson
It is not. git:// protocol would need the git-daemon, as I suggested
earlier. With ssh, you have to say "ssh://hostname/c/that-repository/".
ssh-agent cmd
ssh-add <path to my private key>
ssh <username>@<hostname>
with the command shell set to c:\windows\system32\cmd.exe, I am logged into the server correctly. If I change the command shell to git\bin\bash.exe, I *think* I am logged in ok to the bash but can't tell for sure as it appears to be black text on a black background. The cursor moves around the screen as I would expect if I type "ls" and "cd .." etc. Empirical evidence, shall we say.
However:
git clone ssh://<username>@<hostname>/path/to/repository
fails with:
fatal: protocol error: bad line length character
fetch-pack from 'ssh://<username>@<hostname>/path/to/repository' failed.
which I've google around but the closest I've is one or two threads like: http://kerneltrap.org/mailarchive/git/2007/1/20/236273
On a related theme, would I need to go through ssh-agent/ssh-add each time I wanted to push or pull? I can't see anything in git-config to suggest to I can specify a default private key to use for ssh connections, so I can't see how it would know to use a key.
Somehow I got a feeling that this was a pretty disguised question. To
answer it: post-commit hooks work. You just have to enable them. In
msysGit, you do that by renaming the hook from "post-commit-disabled" to
"post-commit".
Heh. It was more of a "heads up, here's what's coming next if I can get all this cloning to work ;)". Good to know it is ready to go.
Cheers
L
Johannes Sixt
> On 27/02/2008, Johannes Schindelin <Johannes....@gmx.de> wrote:
> git clone ssh://<username>@<hostname>/path/to/repository
FWIW, to test a git connection, use:
git ls-remote ssh://<username>@<hostname>/path/to/repository
This is as close to the metal as can be. It avoids shell scripts on the client
side and still exercises the server in a way that you also need for clone.
-- Hannes
Lee Henson
Thanks for that. I'm pretty sure my problem is with some combination
of ssh-agent/ssh-add/ssh. Running ssh -v <hostname> fails on
authenticating the key. Putty succeeds, so I need to try and isolate
the difference between the two.
L
On Feb 28, 9:44 pm, Johannes Sixt <johannes.s...@telecom.at> wrote:
> On Wednesday 27 February 2008 17:09, Lee Henson wrote:
>
Johannes Schindelin
On Wed, 27 Feb 2008, Lee Henson wrote:
> git clone ssh://<username>@<hostname>/path/to/repository
>
> fails with:
>
> fatal: protocol error: bad line length character
> fetch-pack from 'ssh://<username>@<hostname>/path/to/repository' failed.
I guess this is a problem with binary streams erroneously transferred as
text streams. And that is probably in freeSSHd.
Ciao,
Dscho