Re: GIT and SSH

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 28, 2011, 11:02 UTC
Message-ID: <m38vlxez79.fsf@localhost.localdomain>
In-Reply-To: <20111228101512.GA2192@beez.lab.cmartin.tk>

Carlos Martín Nieto <cmn@elego.de> writes:

> On Wed, Dec 28, 2011 at 11:55:24AM +0200, Dov Grobgeld wrote:

Show 5 quoted lines

> > Git supports multiple transport protocols. Among them are git, ssh,
> > and https. (You can also use direct file system access, but it is
> > questionable whether to call that a protocol). Each of the protocols
> > have their advantages and drawbacks. The git protocol is only used for
> > reading, and not for writing, but is supposed to be very fast. The

FYI git:// protocol can theoretically be used for pushing, but it is not recommended because git:// protocol is not authenthicated - that is why you need to enable pushing via git:// explicitly.

Just git trivia.

Show 15 quoted lines

> > common firewall filtering of the git protocol port 9418 is another
> > problem. ssh is the prefered protocol for writing to a remote
> > protocol. But if ssh is filtered, then http/https may be used, which
> > is very slow for large repositories, but it has the advantage that it
> > is the least blocked protocol.
> 
> Slow for large repositories? Are you thinking of the dumb HTTP
> transport? That one shouldn't be used for doing any serious work. The
> Smart HTTP transport is just the git smart protocol (the same one
> git:// and ssh:// URLs speak) wrapped inside HTTP communication. The
> negotiation phase is a more expensive than with either git or ssh, as
> HTTP is stateless and you need to remind the remote what you want and
> what you've already agreed on, but the actual transfer of data is done
> the same way than with the others so overall it shouldn't be that
> noticeable.

Note that for "smart" transports ("smart" HTTP, SSH) you need to have
git installed on server, or at least have git-upload-pack and
git-receive-pack somewhere (you can configure client where it is to be
found on server).
 
Note that git uses curl for both smart and dumb HTTP transports, so
things like 'http_proxy' and 'HTTPS_PROXY' environment variables
should work.

Show 8 quoted lines

> Now, to the OP's concerns: yes, the ssh transport does generate ssh
> transport, as that's the whole point. You authenticate against the
> remote machine's ssh daemon and run git-upload-pack or
> git-receive-pack as needed (for fetching or pushing). If corporate
> policy doesn't allow ssh you should either fix the policy or use the
> smart HTTP protocol, though this involves messing with passwords and
> their associated problems. I'm not saying ssh keys don't have their
> complications, but I much prefer them.

Note that if the problem is giving shell accounts with SSH access, the
solution is to use one of git repository management tools, like
Gitosis (Python + setuptools, no longer developed) or Gitolite (Perl).
From what I remember both use _single_ *restricted* account and
public-key authenthication.
 
If I am not mistaken Gitolite can help with "smart" HTTP transport
access too.

Show 5 quoted lines

> We can't help you diagnose why your clone is stalling without more
> information. It could be that the connection between the computers is
> flaky, git trying to take too much memory on the remote or local
> machines or any number of things. See if setting GIT_TRACE=1 in the
> environment helps to see what's going on.

Or even undocumented (!) GIT_TRACE_PACKET.

-- 
Jakub Narebski