

A kernel.org status update (no more SSH for developers) - JoshTriplett
http://news.gmane.org/find-root.php?message_id=%3C4E7D1409.1010802%40zytor.com%3E

======
djmdjm
"we will start sending out new ssh credentials to the active developers who
had kernel.org accounts before"

um no. You _should_ be asking developers to send you new SSH credentials.
Generating users' private keys on their behalf is completely unnecessary and
provides extra opportunities for attackers to snarf them.

~~~
rhizome
Yes, this is weird. There has to be more to the reasoning.

------
maaku
we use gitolite with git hooks, and no trouble so far...

and why ask generate private keys instead of asking users to submit public
keys? Less work and more secure.

~~~
andrewcooke
why is it more secure? don't you end up with a whole pile of private keys in
one place?

and they will still need those private keys, as far as i can see. so you need
to send them over what, email...?

~~~
cobrabyte
The gitolite permissions file is fairly robust. Each person who needs to
access Git repo(s) sends you their _public_ key (i.e. id_rsa.pub) and only
their public key is stored on the server. Since access to the gitolite server
is really just an SSH connection, the keys are stored in
~/.ssh/authorized_keys and managed via gitolite.

So, you get the tried-and-true security flow of public keys within SSH.

As for the user/group management, gitolite lets you provide access to various
repos (with settable read, read/write, read/write/+ permissions) to
individuals identified by the public key files you've received from your Git
contributors.

Not sure if that's what you were wondering but we've had a fairly easy time
providing secure access to our own private Git repos using gitolite.

Server-side hooks are going to be an interesting problem to solve for
kernel.org.

~~~
andrewcooke
i know how gitolite works; i've used it myself.

what i am asking about is the central generation of private keys. that is not
necessary for gitolite. the normal (secure) process is to have users provide
their public keys.

what i would like to know is how kernel.org generating private keys for users
(in one central location, and then, i assume, distributing them) can be "more
secure".

~~~
cobrabyte
Gotcha. Yeah, there's no reason for users not to generate their own key pair
and submit the public keys via whatever means makes the most sense. It's going
to take someone a great deal of time to gather all the public keys, rename
them and add them to the gitolite system.

There are a couple of web admin panels that can sit in front of gitolite and
manage keys, repos and permissions. I've not tried any of them but hopefully
someone is looking into that. Makes a lot more sense than generating key pairs
and distributing private keys to everyone.

------
KonradKlause
"no more SSH for developers" is wrong. Please read carefully: " This new
infrastructure will no longer have shell access to the git repositories"

kernel.org is more than one server...

------
X-Istence
How many developers were actually using git hooks? I know I have a couple of
git hooks, client side, but so far have not had the need to have them server
side.

~~~
kev009
I don't know about kernel.org stats, but these are pretty useful server side
for sanity checks (i.e. enforce commit message rules), notifications (IRC,
XMPP, etc), and external integration (Gerrit, Jenkins CI, etc).

------
jbert
I'm missing something. If the goal of revoking ssh access is to stop kernel
devs being able to run arbitrary commands on kernel.org servers...surely you
can't give them permissions to set their own commit hooks?

If an attacker compromises a kernel dev, instead of using their ssh access to
run cmds on kernel.org, they just use their hook access to run cmds on
kernel.org.

------
phzbOx
As they say "Don't fix what isn't broken".

------
zobzu
Real men install mandatory access control

