Re: git + ssh + key authentication feature-request

From: Mark Wooding <mdw@distorted.org.uk>
Date: Feb 9, 2006, 00:14 UTC
Message-ID: <slrndul2bq.2i8.mdw@metalzone.distorted.org.uk>
In-Reply-To: <7v4q39o3xs.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 5 quoted lines

> So while you could make a repository "/pub/project.git" the home
> directory of _one_ UNIX user, and store her key in the file
> "/pub/project.git/.ssh/authorized_keys", that would not work
> very well for a shared repository setup if you want to be able
> to tell more than one physical users apart.

Ahh! But you can. The trick is to set the remote user's identity based on the key he uses to authenticate himself. This doesn't work if you use password authentication. You add items of the form `environment="VAR=VALUE"' to the end of each authorized_keys entry, as appropriate for whoever it is that owns the corresponding private key; the GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL} variables are ideal choices to set here. You could set some other variables and do some more sophisticated checking of who's doing what, which would require souping up git-daemon somewhat, but I don't think it's beyond the realms of possibility.

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?

> You _could_ tell them to use the same -l option and log-in as the same
> UNIX user with their own keys, though.  But that way you cannot tell
> which developer pushed into the repository (of course if you trust the
> commits, commit log message would say the committer ident).

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.

-- [mdw]