* Re: git + ssh + key authentication feature-request
2006-02-08 23:23 ` Nicolas Vilz 'niv'
@ 2006-02-08 22:45 ` Linus Torvalds
2006-02-09 0:43 ` Nicolas Vilz 'niv'
2006-02-08 22:56 ` Junio C Hamano
2006-02-08 23:35 ` Alan Chandler
2 siblings, 1 reply; 15+ messages in thread
From: Linus Torvalds @ 2006-02-08 22:45 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
On Thu, 9 Feb 2006, Nicolas Vilz 'niv' wrote:
>
> 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..
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: git + ssh + key authentication feature-request
2006-02-08 22:45 ` Linus Torvalds
@ 2006-02-09 0:43 ` Nicolas Vilz 'niv'
0 siblings, 0 replies; 15+ messages in thread
From: Nicolas Vilz 'niv' @ 2006-02-09 0:43 UTC (permalink / raw)
To: git
Linus Torvalds wrote:
> 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".
done..
> 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.
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: git + ssh + key authentication feature-request
2006-02-08 23:23 ` Nicolas Vilz 'niv'
2006-02-08 22:45 ` Linus Torvalds
@ 2006-02-08 22:56 ` Junio C Hamano
2006-02-09 0:14 ` Mark Wooding
2006-02-09 0:33 ` Nicolas Vilz 'niv'
2006-02-08 23:35 ` Alan Chandler
2 siblings, 2 replies; 15+ messages in thread
From: Junio C Hamano @ 2006-02-08 22:56 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
Nicolas Vilz 'niv' <niv@iaglans•de> 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).
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: git + ssh + key authentication feature-request
2006-02-08 22:56 ` Junio C Hamano
@ 2006-02-09 0:14 ` Mark Wooding
2006-02-09 0:40 ` Junio C Hamano
2006-02-09 0:33 ` Nicolas Vilz 'niv'
1 sibling, 1 reply; 15+ messages in thread
From: Mark Wooding @ 2006-02-09 0:14 UTC (permalink / raw)
To: git
Junio C Hamano <junkio@cox•net> 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]
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: git + ssh + key authentication feature-request
2006-02-09 0:14 ` Mark Wooding
@ 2006-02-09 0:40 ` Junio C Hamano
2006-02-09 0:55 ` Mark Wooding
0 siblings, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2006-02-09 0:40 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
Mark Wooding <mdw@distorted•org.uk> writes:
> 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?
Correct modulo s/git-daemon/git-shell/.
> 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.
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: git + ssh + key authentication feature-request
2006-02-09 0:40 ` Junio C Hamano
@ 2006-02-09 0:55 ` Mark Wooding
0 siblings, 0 replies; 15+ messages in thread
From: Mark Wooding @ 2006-02-09 0:55 UTC (permalink / raw)
To: git
Junio C Hamano <junkio@cox•net> wrote:
> Correct modulo s/git-daemon/git-shell/.
D'oh! Finger trouble!
> 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.
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]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: git + ssh + key authentication feature-request
2006-02-08 22:56 ` Junio C Hamano
2006-02-09 0:14 ` Mark Wooding
@ 2006-02-09 0:33 ` Nicolas Vilz 'niv'
2006-02-08 23:50 ` Linus Torvalds
2006-02-08 23:55 ` Junio C Hamano
1 sibling, 2 replies; 15+ messages in thread
From: Nicolas Vilz 'niv' @ 2006-02-09 0:33 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> Nicolas Vilz 'niv' <niv@iaglans•de> 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..
[... 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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: git + ssh + key authentication feature-request
2006-02-09 0:33 ` Nicolas Vilz 'niv'
@ 2006-02-08 23:50 ` Linus Torvalds
2006-02-09 1:16 ` Nicolas Vilz 'niv'
2006-02-08 23:55 ` Junio C Hamano
1 sibling, 1 reply; 15+ messages in thread
From: Linus Torvalds @ 2006-02-08 23:50 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: git + ssh + key authentication feature-request
2006-02-08 23:50 ` Linus Torvalds
@ 2006-02-09 1:16 ` Nicolas Vilz 'niv'
0 siblings, 0 replies; 15+ messages in thread
From: Nicolas Vilz 'niv' @ 2006-02-09 1:16 UTC (permalink / raw)
To: git
Linus Torvalds wrote:
>
> 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".
>
[...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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: git + ssh + key authentication feature-request
2006-02-09 0:33 ` Nicolas Vilz 'niv'
2006-02-08 23:50 ` Linus Torvalds
@ 2006-02-08 23:55 ` Junio C Hamano
2006-02-09 1:06 ` Nicolas Vilz 'niv'
1 sibling, 1 reply; 15+ messages in thread
From: Junio C Hamano @ 2006-02-08 23:55 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
Nicolas Vilz 'niv' <niv@iaglans•de> writes:
> 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?
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: git + ssh + key authentication feature-request
2006-02-08 23:55 ` Junio C Hamano
@ 2006-02-09 1:06 ` Nicolas Vilz 'niv'
0 siblings, 0 replies; 15+ messages in thread
From: Nicolas Vilz 'niv' @ 2006-02-09 1:06 UTC (permalink / raw)
Cc: git
Junio C Hamano wrote:
> Nicolas Vilz 'niv' <niv@iaglans•de> writes:
>
>
>>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?
>
>
> That is not a git question but you are using me as an ssh
> helpdesk. See ssh_config(5).
i didn't recognize that it had nothing to do with git.
Thank you very much for your help and your time. :)
Nicolas
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: git + ssh + key authentication feature-request
2006-02-08 23:23 ` Nicolas Vilz 'niv'
2006-02-08 22:45 ` Linus Torvalds
2006-02-08 22:56 ` Junio C Hamano
@ 2006-02-08 23:35 ` Alan Chandler
2 siblings, 0 replies; 15+ messages in thread
From: Alan Chandler @ 2006-02-08 23:35 UTC (permalink / raw)
To: git
On Wednesday 08 February 2006 23:23, Nicolas Vilz 'niv' wrote:
> 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..
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.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply [flat|nested] 15+ messages in thread