Please create an account to participate in the Slashdot moderation system


Forgot your password?
Security Linux

Linux Kernel Git Repositories Add 2-Factor Authentication 49

LibbyMC writes For a few years now Linux kernel developers have followed a fairly strict authentication policy for those who commit directly to the git repositories housing the Linux kernel. Each is issued their own ssh private key, which then becomes the sole way for them to push code changes to the git repositories hosted at While using ssh keys is much more secure than just passwords, there are still a number of ways for ssh private keys to fall into malicious hands. So they've further tightened access requirements with two-factor authentication using yubikeys.
This discussion has been archived. No new comments can be posted.

Linux Kernel Git Repositories Add 2-Factor Authentication

Comments Filter:
  • Oh no. (Score:4, Funny)

    by i kan reed ( 749298 ) on Monday August 18, 2014 @04:13PM (#47698059) Homepage Journal

    Someone might commit code to our open source project. We can't have that.

    • by Anonymous Coward

      Yes, malicious actors. The Linux kernel repos have never been a free-for-all.

      • Re:Oh no. (Score:5, Funny)

        by i kan reed ( 749298 ) on Monday August 18, 2014 @04:19PM (#47698115) Homepage Journal

        Okay, so once again I have to be reminded that no one is allowed to joke about the Linux kernel, because the distros are responsible for packaging a sense of humor.

  • You mean I can no longer use my Authenticator for my commits?

  • by Zan Lynx ( 87672 ) on Monday August 18, 2014 @04:35PM (#47698227) Homepage

    Finally the Linux kernel which runs almost the entire Internet is as secure as my MMORPG accounts. About time. :P

  • Let's see:
    - Authenticated kernel source.
    - Checksummed distro ISO.
    - Eeprom subverted thumb drive.

  • by tota ( 139982 ) on Tuesday August 19, 2014 @03:48AM (#47701477) Homepage
    The user is not issued a key, he generates one and gives it to the repository administrator to get ssh access. This process is called *generating* a key, and you can publish the public key to anyone, including the repository administrator which will then use it to grant you access. The private key however.. should remain private.

    The point is that only *you* should ever have access to the private key, having someone else generate it (as is suggested by the wording in this article) would be very unusual, as you would not want to use this key for anything else, and someone else would have your private key for no good reason. Someone could even potentially use this key to fake your identity in commits.

    The problematic wording is here: "Each is issued their own ssh private key".

    • by Mr_Icon ( 124425 )
      There is no mistake here -- the ssh private keys are generated on the provisioning system, encrypted to the developer's PGP key (which is verified using the PGP web of trust) and then emailed out. The developer then decrypts the ssh private key on their workstation using their own PGP private key. Our copy of the ssh private key is destroyed in the process, so we only keep the ssh public key. PGP web of trust is king in the world.
      • by tota ( 139982 )
        Really, that's interesting and I stand corrected. Thanks.
        I still fail to see the benefit of generating the key on the system and sending it PGP encrypted. Why not just generate yourself and send it to the administrators PGP encrypted instead? (as per the reply below, using 3rd party private keys is bad practice)
        • by Mr_Icon ( 124425 )
          Least amount of back-and-forth between the developer and the admin ("sorry, your key has to be at least 2048 bits", "you forgot to sign your mail", "sorry, I sent you guys the wrong key"), plus it helps assure it's a dedicated SSH key and isn't shared between many other projects and therefore copied across workstations. Mostly, though, it reduces hassle.

Disraeli was pretty close: actually, there are Lies, Damn lies, Statistics, Benchmarks, and Delivery dates.