Re: [RFC] Secure central repositories by UNIX socket authentication

> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>
>>> Hmm.  core.sharedrepository is sometimes a bad solution.
>>>
>>> core.sharedrepository means I need to give write access to both the 
>>> refs database and the object database to all members of the project. 
>>> Some of whom may not be able to be trusted with tools like "rm", but 
>>> who need real shell access to that system anyway.  And sometimes 
>>> management won't allow users to have two accounts on the same system 
>>> (one that is fixed to git-shell, and one that has a real shell) 
>>> because the world would implode if a user was given two different 
>>> accounts for two different access purposes.
>>
>> Ok, that was the motiviation I did not get from your original message. 
>> It begins to make sense somewhat.
>>
>> Another approach to do the same I can think of, without having to add 
>> 50 new accounts for 50 users, would be to collect a ssh key from each 
>> of these 50 users, and have 1 line per user in the authorized_keys file 
>> of gitadmin.gitadmin user (who owns the repository with the paranoia 
>> hook that decides the authorization aspect of the repository).  The 
>> authentication would come from the environment="Name=value" option in 
>> the authorized_keys file. Each of your aunt tillies can push or fetch 
>> over ssh using the key she has in the gitadmin.gitadmin's 
>> authorized_keys file.
>
> Yea.  The downside to this is we have to maintain that authorized_keys 
> file.  Today each user can generate their own SSH key and upload to 
> their own authorized_keys file.
>
> I've had enough cases of users losing their SSH key and needing to 
> recreate it that I'd rather not have to manage a 50 user long 
> authorized_keys file.