git + ssh + key authentication feature-request

Hi guys,

first of all, great work.

I just discovered git and i like it.

I would like to ask if it is possible to use ssh keys to authenticate via ssh on a git repository via git-pull/git-push. Since ssh supports them, wouldn't it be nice to use them in git, too?

The layout would be following:

you have a system user with a git-shell and several keys in .ssh/authorized_keys ... these are the keys of your contributors. They are allowed to login and work with the repository.

I haven't found a posibility to get this. Maybe I haven't discovered it, yet...

Sincerly Nicolas

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

Please read what has been discussed within the last couple of weeks at least. I could say the last couple of months but I know that is asking too much ;-).

http://thread.gmane.org/gmane.comp.version-control.git/15462

Junio C Hamano wrote:

Sorry, i haven't found that, yet, so i asked..

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 can still live with the password thing :)

Sincerly Nicolas

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

That is very much part of how the whole git-shell usage was envisioned.

Create a "project" account on some shared machine, create the project(s) in that accounts home directory, and set the login shell for that project to "git-shell".

Then you ask people who are part of the project to send in some ssh key for that project. Then add those keys to the authorized_keys2 file for the project, and voila, you all your participants can pull and push into it but do not get any other access to the machine.

It _should_ all work perfectly fine. There are features you may want to add, like logging (but sshd does some of that for you) and various "admin" commands in addition to just plain push/pull. git-shell was really just a quick hack, and I don't know if anybody actually uses it.

In other words, it hasn't exactly been tested,

		Linus

Linus Torvalds wrote:

done..

I would like to use it.. i searched for something like scponly for ssh just for git.. and I found git-shell.

as long as i can modify and setup git-repositories myself, i haven't needed admin-commands, yet...

as mentioned in the thread, i still search for a posibility to tell git to send my identify-file... and possibly set an alias for this command :)

ssh with bash for this account and the keys works... ssh with git-shell does work, too... (What do you think I am? A shell?) but git with keys and ssh transport, that is what i don't get working :)

Nicolas

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

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

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?

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]

Mark Wooding <mdw@distorted.org.uk> writes:

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

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 <junkio@cox.net> wrote:

D'oh!  Finger trouble!

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]

Junio C Hamano wrote:

[... how sshd operates ...]

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:

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

Linus Torvalds wrote:

[...ssh config...]

i will do that.. :))

I thank you all for your help.

Nicolas

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

That is not a git question but you are using me as an ssh helpdesk. See ssh_config(5).

The answers are:

	IdentityFile
        User

For example, I have this in my .ssh/config on my local machine:

    Host osiris.pyramid.com
      User junio
      IdentityFile ~/.ssh/osiris-pub
      ForwardAgent no
      ForwardX11 no

Without "User", it would send out "junkio", so I have that line to override it (I could do it with -l command line, but there is no point because that is I would use _always_ to go there). Without "IdentityFile" it would use ~/.ssh/identity (same rationale with -i), which is the identity file I usually use for other sites.

Junio C Hamano wrote:

i didn't recognize that it had nothing to do with git.

Thank you very much for your help and your time. :)

Nicolas

On Wednesday 08 February 2006 23:23, Nicolas Vilz 'niv' wrote:

This sounds like you haven't got sshd set up correctly. You can get it to log you in soley based on keys, and whether or not you give a password is then dependent soley on whether your private key has a pass phrase or not and then whether or not you are using some ssh-agent to remember them for you.

I have it setup so that access to ssh controlled accounts is soley via key.

Private keys remaining on fixed computers at home have no passphrase, my laptop has a private key with a passphrase which I enter once on login.

I have several accounts around the place with my public keys enumerated in their .ssh/authorized_keys file, so I have been able to contact git repositories with urls like

git@www.chandlerfamily.org.uk
www-data@www.chandlerfamily.org.uk
 and for my own account
just www.chandlerfamily.org.uk

all without entering a password.

But following the discussion thread Junio pointed to I have converted everything to shared repositories and I now only use my own account to log in.