Hacker News Reader

Comment by tedunangst | Hacker News Reader

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

View on HN

Take a look at the YubiKey NEO.

https://www.yubico.com/products/yubikey-hardware/yubikey-neo...

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:

http://forum.yubico.com/viewtopic.php?f=26&t=1171

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.

https://gpgtools.org/

Configure gpg-agent:

  $ cat ~/.gnupg/gpg-agent.conf 
  pinentry-program /usr/local/MacGPG2/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac
  enable-ssh-support
  write-env-file
  use-standard-socket
  default-cache-ttl 600
  max-cache-ttl 7200

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:

http://support.gpgtools.org/discussions/problems/30646-gpg-a...

You can use it on 10.10, but once in a while gpg-agent gets stuck and you'll have to kill/restart it. I've posted a script on that support forum.

Works great on 10.9 and Linux.

Brilliant, thank you so much for this. I'm looking forward to having everything on my Yubikey!

Thanks for this. Will investigate getting a Yubikey now.

http://florin.myip.org/blog/easy-multifactor-authentication-...

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.

[1] https://blog.habets.se/2013/02/GPG-and-SSH-with-Yubikey-NEO

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.

Thanks for the info! I was hoping it was more secure than a simple USB flash drive. This seems like a really good way to improve key security.

Do you know of any talks/articles attempting to break the YubiKey NEO in a similar way to how cloning attacks against SIM cards work?

On a Mac, you can store the key password in Keychain. The key is still protected but you don't need to enter the password on every push.

Just create the key and then try to use it. An OS X password dialog window will pop up. Enter the key password and check the box to save it. Done.

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.

What does that help? Doesn't the ssh-agent keep the keys in memory too?

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.

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>

Maybe I'm missing something, but under what scenario would I not be keeping my private key private and client-side? That being the whole point of it.

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.

Reply on news.ycombinator.com