What percentage of ssh keys are encrypted, do you estimate or wager? I can't imagine that they haven't built factoring hardware but I agree that scale is a problem. I also can't imagine that they need to use factoring hardware if say 80% (I'm just guessing, could be much higher) of the ssh private keys are just chillin' on disks unencrypted, there has to be tons of other exploits to get those.
Server keys? Probably closer to 99.999% are just chillin' on disk.
Client keys? How many people use github, but don't want to enter a password on every push and aren't hardcore about setting up agents (esp. on Windows)?
It's basically a smartcard in the form factor of a nano-USB-stick. You can generate a pair of public/private SSH keys, with the private key remaining forever on the token.
Then setup gpg-agent in ssh-agent emulation mode (it's three lines in a file) and voila! you have hardware-backed authentication.
I'll probably write a HOWTO soon, but until then have a look at this:
It's unnecessarily complicated as described in the top post, but read the comments below, too. The real setup is dead simple - just a few lines in gpg-agent.conf and one of the .*profile files.
I'd love the writeup if you get the chance, I've looked at various places on how to do it (my brother bought me a Yubikey for Christmas) but like you said, it seems more complex than it should be. I'm interested to see how it'll go with OS X.
Generate public/private key pair on the NEO smartcard:
Run 'gpg --card-edit'
In the menu, choose 'admin'. Then choose 'generate'. Then 'quit'.
That's it. The private SSH key will remain on the smartcard forever; it will never leave it, not even during authentication. It cannot be extracted (well, maybe the NSA can, who knows).
To extract the public SSH key from the card, run 'ssh-add -L > my-public-key.pub'
You may want to edit the name (the third field) at the end of the key.
I'm 99% sure ssh-add -L works on any Unix system, you don't need anything preconfigured, just plug the token into it and run the command. This way you can easily get your public key no matter where you are.
The smartcard has a user PIN and an admin PIN. The default user PIN is '123456'. The default admin PIN is '12345678'. It is recommended to change them.
After 3 mistakes entering the user PIN, the card locks up and you'll need to unlock it with the admin PIN.
After 3 mistakes entering the admin PIN, the card is dead forever. Be careful with the PINs.
Read "man gpg", options --card-edit, --card-status, and --change-pin.
You will have to enter the user PIN when you authenticate SSH. It's cached for a while (see below).
#########################
Configure Linux or OS X to use ssh key authentication with the NEO:
Install gnupg, either from Homebrew or from GPG Tools (on OS X), or via repos on Linux.
On Linux, I think you don't need the pinentry-program line, so remove it (not sure). Or experiment with various pinentry utilities, see what works for you; there should be a pinentry somewhere on your system after you install gnupg, and usually it's text-mode.
The value shown above is for OS X with GPG Tools, which is a GUI mode pinentry. If you install gnupg via Homebrew, read what I said above about Linux. Or google for the GUI mode pinentry for OS X - it's a separate download, made from an older GPG Tools version, that you can install along with Homebrew gnupg.
$ tail -n 7 .bash_profile
GPG_TTY=$(tty)
export GPG_TTY
if [ -f "${HOME}/.gpg-agent-info" ]; then
. "${HOME}/.gpg-agent-info"
export GPG_AGENT_INFO
export SSH_AUTH_SOCK
fi
The GPG_TTY is not needed with the GUI pinentry that comes with GPG Tools on OS X, but might be needed for the simpler text-mode pinentries that come with other gnupg distros.
On Linux, or on Mac with gnupg installed from Homebrew, you need to launch gpg-agent upon logging in (GPG Tools will do that automatically for you). One way that seems to work well (checked with Homebrew gnupg on OS X, and with the Linux gnupg) is to add this to .bash_profile:
eval $(gpg-agent --daemon)
To use it, put your public key on a server, plug the NEO into USB, and run 'ssh user@host'. pinentry will ask you for the user PIN. And that's it.
##########################
WARNING:
PCSC is broken on OS X 10.10. If you're on 10.9, stay there if you plan to use the NEO (or any smartcard for that matter). More details here:
Does using the Yubikey in this manner protect your keys even if your machine has malware on it? I read through this tutorial [1], and they say you need read/write access to the device, so it seems to me like malware could access your keys while the smartcard is plugged in. If this is the case, I'm not sure how this setup is any more secure than simply keeping your keys on a USB flash drive and plugging it in whenever you need to use ssh.
The private SSH key never leaves the smartcard, not even during authentication. It is not exposed to the OS or any process, at all. You can't extract it at all (maybe the NSA can, who knows). The actual authentication takes place on the token, not in a process on your Unix system.
The only thing that the malware can do is issue an authentication request while the token is plugged in. That's all. If the PIN is not cached, you'll be prompted to enter it, and you'll be like "why is it asking me to enter the PIN?"
Maybe they could run a spy debugger on gpg-agent, but again, this would not give them your private key.
Client keys? How many people use github, but don't want to enter a password on every push and aren't hardcore about setting up agents (esp. on Windows)?
I encourage everyone to use encrypted keys on all platforms. You can set up the regular ssh-agent in git bash, and Atlassian's Source Tree can also use encrypted keys.
I don't see the point of encrypted keys, if my computer is compromised it is a trivial matter for an attacker to log input and get the password. If the computer is stolen, the disk encryption should be enough.
There are many ways to compromise a computer without installing something and having the user later provide input. Easiest example is a lost or stolen laptop - if it's not encrypted, you can get the contents of the disk, but the user isn't going to be around to provide more input.
There are many ways to compromise a computer without installing something and having the user later provide input. Easiest example is a lost or stolen laptop - if it's not encrypted, you can get the contents of the disk, but the user isn't going to be around to provide more input.
Client keys: chk out Userify :) (shameless plug follows) You keep your private key private client-side. (use an agent or not). Userify deploys user/sudo/key to your project servers. </plug>
Most key "management" systems like to hold onto your private key for you and provision your connection for you. That's insane and defeats the whole point (as you point out)!!
As far as server-side, automation keys are often 'server' side (where the server is itself a client). Userify can manage and deploy those keys as well, but it's not super easy (yet) -- currently, you still have to 'invite' a (fake) user, create a new user account (company_backup_account or whatever), and then choose all the servers that you want that public key deployed to. That part could definitely be easier.. and soon will be.
