A kernel.org status update (no more SSH for developers) | Hacker News Reader

A kernel.org status update (no more SSH for developers)

news.gmane.org

85 pointsJoshTriplett19 comments

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

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

Perhaps the idea is to mail a gpg-encrypted temporary password that can be used to log in over ssh and set up keys.

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.

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

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.

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

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.

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

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.

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

Junio (git's maintainer) was using a hook to pre-generate html documentation and manpages. These would get committed to "html" and "man" branches so that others could check them out without needing to have the asciidoc tools installed.

http://git-blame.blogspot.com/2011/09/return-of-htmlman-bran...

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.

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

Real men install mandatory access control

Reply on news.ycombinator.com