Re: git + ssh + key authentication feature-request

Mark Wooding [off-list ref] writes:

It's important that your users can't use this SSH access to mess with
the shared user's SSH configuration itself, but, hey, that sort of
restricted access is what git-daemon is for, right?

Correct modulo s/git-daemon/git-shell/.

I think the problem there is more that the commits themselves were
created elsewhere, where this server wasn't watching, and therefore it
pretty much has to take the committer and author information there on
trust.

That's an different issue.  Anybody could create bogus commits
all they want based on somebody else's history.  Making
refs/{heads,tags}/ pointers to point at the tip of a development
tail that contains such bogus commits is something you would
want to have control upon.

For example, Documentation/howto/update-hook-example shows
Carl's idea to implement access control using the unix user
identity (because it assumes you set up one home directory per
developer to use public key authentication to cause sshd to give
a true unix uid to an incoming connection) to make sure who can
update which head.  By updating a branch head, the developer is
asserts that the development trail that led to it is something
she feels valid.

Now, you brought up an interesting way to do this without using
unix uid.  Some sshd installations do not honour environment=
settings, but that problem aside, you could define a token, say
GIT_USER, with different value on each line in the shared
authorized_keys file so that you can distinguish incoming
developers that share the same "home directory", and change the
example hook Carl gave us to use that token instead of the unix
user identity.  I'd imagine that would work quite well.

Junio C Hamano [off-list ref] wrote:

Correct modulo s/git-daemon/git-shell/.

D'oh!  Finger trouble!

Now, you brought up an interesting way to do this without using
unix uid.  Some sshd installations do not honour environment=
settings, but that problem aside, you could define a token, say
GIT_USER, with different value on each line in the shared
authorized_keys file so that you can distinguish incoming
developers that share the same "home directory", and change the
example hook Carl gave us to use that token instead of the unix
user identity.  I'd imagine that would work quite well.

Quite possibly.

Don't give me the credit here, by the way.  I completely stole this
whole idea from the Subversion documentation: see `SSH configuration
tricks' in 

  http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html

at the bottom.

Oh, any my mistake: the `environment...' options go at the beginning of
an authorized_keys line, not at the end.

It's so time I went to sleep.

-- [mdw]