Re: git + ssh + key authentication feature-request

Nicolas Vilz 'niv' <niv@iaglans.de> writes:

I do not know where you are getting the password idea.

The conclusion of that thread is that it is not worth trying to co-mingle more than one physical developer into one home directory, and does not have much to do with use of password or public key authentication.

That thread describes:

 - you can use ssh public key authentication for developers;

 - you do not have to give them full shell access by using
   git-shell;
   
 - HOWEVER you cannot tell each developers apart if you add one
   key per developer to the same $HOME/.ssh/authorized_keys file.

The last point is not about git at all, but comes from how ssh daemon operates. It roughly goes like this:

 - The client says "I am me at the remote host, use this public
   key to prove that to the other end".  Often you do not have
   to give -l and -i but when you fully spell out the command
   line, it would be something like:

	$ ssh -l me -i identity-file remote.host.example.com

   Your client sends "me" and the public key to the remote end.

 - The ssh daemon running on the remote site says, "Hmph, let's
   see if you are really "me" as you claim."  It does the
   following things:

    1. Look "me" up from its user database (be it /etc/passwd,
       NIS or LDAP) to find out the user's home directory.
       Let's say the "struct passwd.pw_dir" says it is
       "/home/me".

    2. Check to see if /home/me/.ssh/authorized_keys exists, all
       the elements in the path to the file is secure (e.g. if
       /home/me/.ssh can be modified by somebody other than
       "me", what is in authorized_keys is not trustworthy).
       That means /home/me/.ssh/authorized_keys must be owned by
       "me" and at least mode 0644 or stricter.

    3. Reads the keys in that file, and finds what is sent as
       the public key from the client.

    4. Uses that public key to challenge the client to make sure
       the client has the corresponding private key.

What this implies is that sharing the home directory among multiple UNIX users would not work with ssh daemon the way you expect. The check in step 2 would fail for all but one user.

Being able to list more than one key in authorized_keys is so that you can use more than one key to become the _same_ user, and does not give you the ability to become a user other than the one that owns that home directory on that remote host.

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.

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).