Re: git + ssh + key authentication feature-request

Nicolas Vilz 'niv' [off-list ref] writes:

in my case it would be only one system-user which has full access to
several repositories. At this time, the users which use that account,
have to give a password, which isn't that bad... it would be easier
and more secure for me, not to give a password, but ask the users for
the ssh pubkey..

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

Junio C Hamano wrote:

Nicolas Vilz 'niv' [off-list ref] writes:

quoted

in my case it would be only one system-user which has full access to
several repositories. At this time, the users which use that account,
have to give a password, which isn't that bad... it would be easier
and more secure for me, not to give a password, but ask the users for
the ssh pubkey..

[... how sshd operates ...]

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 this (last) scenario would match my thoughts best :)

Exactly that was, what i was trying to do, although I couldn't tell git 
to send my identify-file. That was (more or less) my initial-question 
(howto do that, the ssh option -i) :)

You got a point which i haven't recognized, yet...

I really can't tell later on which developer pushed unless i trust the 
commit-messages. I will think about that.

So, how do i tell git to send my identity-file to sshd? And could I set 
an alias like in .git/remotes for that location / identity?

Thank you very much for your explanations and help.

Sincerly
Nicolas

On Thu, 9 Feb 2006, Nicolas Vilz 'niv' wrote:

So, how do i tell git to send my identity-file to sshd? And could I set an
alias like in .git/remotes for that location / identity?

Use a "fake host".

Ie, let's say that your project is "project@host.com", then make each user 
just have in their .ssh/config:

	host project.host.com
		User project
		HostName host.com
		IdentityFile /home/myhome/project-key

and there you are. Just use "project.host.com:repo-name" as the thing you 
pull and push from.

(Yeah, I forget the exact ssh config file format, so you should 
double-check that.)

		Linus

Junio C Hamano [off-list ref] wrote:

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]

Linus Torvalds wrote:

On Thu, 9 Feb 2006, Nicolas Vilz 'niv' wrote:

quoted

So, how do i tell git to send my identity-file to sshd? And could I set an
alias like in .git/remotes for that location / identity?

Use a "fake host".

[...ssh config...]

(Yeah, I forget the exact ssh config file format, so you should 
double-check that.)

i will do that.. :))

I thank you all for your help.

Nicolas