For a few years now we have been mandating a fairly strict authentication policy for those developers 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 kernel.org. 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. Keeping that in mind, we wanted to further tighten our access requirements, but without causing undue difficulties for the kernel developers.
2-factor authentication parlance, a “hard token” is a dedicated physical device that is purpose-built to do nothing else but authentication. A “soft token,” on the other hand, designates a pure-software implementation that is running on a multi-purpose portable computing device (such as a smartphone). If you’ve ever set up “two-step verification” with your Google account or turned on the “code generator” for Facebook, you’ve used a 2-factor authentication soft token. If you’ve ever used an RSA SecurID “key fob” or a Yubikey, you’ve had firsthand experience with “hard tokens.”
At the Linux Foundation, we wanted to make both options available and leave the decision of whether to use a soft token or a hard token in the hands of kernel developers themselves. After all, 2-factor authentication with a soft token is still dramatically more secure than no 2-factor authentication at all. That being said, we wanted to encourage the use of more secure hardware tokens, which is why we contacted Yubico, the makers of Yubikeys, in the hopes that they would be willing to offer a discount to Linux kernel developers. To our amazement and gratitude, Yubico went well above and beyond a simple discount and offered to donate a hundred yubikeys to all Linux kernel developers who currently hold accounts at kernel.org.
We looked at the options available in gitolite, the git repository management solution used at kernel.org, and found a way that allowed us to trigger additional checks only when someone performed a write operation, such as “git push.” Since we already knew the username and the remote IP address of the developer attempting to perform a write operation, we put together a verification tool that allowed developers to temporarily whitelist their IP addresses using their 2-factor authentication token.
Gitolite two-factor authentication script: https://github.com/mricon/totp-cgi/tree/master/contrib/gitolite