
Using a Yubikey for GPG and SSH - gehaxelt
https://0day.work/using-a-yubikey-for-gpg-and-ssh/
======
EngineerBetter
One of our engineers wrote a series of blogs about how to use a Yubikey for
SSH auth, OTP2FA, U2F, and logging into 1Password on shared machines.

[http://www.engineerbetter.com/blog/yubikey-all-the-
things/](http://www.engineerbetter.com/blog/yubikey-all-the-things/)

[http://www.engineerbetter.com/blog/yubikey-
ssh/](http://www.engineerbetter.com/blog/yubikey-ssh/)

[http://www.engineerbetter.com/blog/yubikey-static-
secret/](http://www.engineerbetter.com/blog/yubikey-static-secret/)

[http://www.engineerbetter.com/blog/yubikey-2fa/](http://www.engineerbetter.com/blog/yubikey-2fa/)

I wish AWS supported U2F, it'd make my day a lot less frustrating.

We do a lot of pairing and rotating on shared machines, so it's really danged
useful.

~~~
lrvick
For AWS you can use your yubikey indirectly for now via "Yubico Desktop" or
"Yubico Authenticator" which emulate TOTP mode.

You can then go through the "Virtual MFA" flow in AWS and keep the TOTP secret
inside the yubikey with a touch requirement.

This is nowhere near as ideal as U2F but it is a huge step above Google
Authenticator which stores all secrets in plaintext in an sqlite database.

Also the 2FA support of 1password is entirely cosmetic if an attacker has
malware on your machine. It decrypts your entire database against one secret.

I would encourage consideration of solutions that only decrypt the credential
being reqested that don't expose the decryption key to the system:
[https://github.com/lrvick/security-token-
docs/blob/master/Us...](https://github.com/lrvick/security-token-
docs/blob/master/Use_Cases/Password_Mangement.md)

~~~
stcredzero
_is a huge step above Google Authenticator which stores all secrets in
plaintext in an sqlite database._

...I'm beginning to feel angry again! WTF Google? Why isn't Google
Authenticator using an encrypted store with the keys stored in the iOS
enclave?

~~~
akerl_
This makes it sound like the secrets are just printed out and posted on a
notice board somewhere, which is pretty much straight fearmongering.

The sandboxing between apps on non-jailbroken iOS (and to a lesser extent un-
rooted Android) is such that having the secrets stored in an app's database
renders them secure against basically any attack that doesn't involve physical
access to the device.

Given that the app needs access to the symmetric TOTP keys for it to work,
most of the available other options aren't appreciably changing the security
model. Encrypt the DB with a magic secure-enclave-stored key? Now the app is
just asking to decrypt the DB every time it's opened. What attack are you
worried about where this new setup isn't equally vulnerable?

~~~
fanzhang
If someone gets a hold of your lost phone, without the secure enclave, rooting
it is easy with physical possession. Whereas with a secure enclave, physical
access with a locked device doesn't give the secret away.

~~~
chimeracoder
> If someone gets a hold of your lost phone, without the secure enclave,
> rooting it is easy with physical possession.

Rooting an arbitrary Android phone is not easy, and rooting an arbitrary
Android phone (especially the Nexus/Pixel flagship devices) without wiping the
storage is _really_ not easy.

~~~
fanzhang
After looking around, I agree that standard ways of rooting the phone do
involve wiping it.

However, it still remains that the secret is sitting in plain text on a hard
drive on the phone. If you unplug/unsolder the hard drive, you could just read
it, like a PC.

Another advantage is that if the secure enclave is hardware/firmware linked to
authentication (fingerprint / password), then there would need to be a
vulnerability in that hardware process for a remote users to get a break.

This is the second factor of a 2FA, so I agree that in most cases, it won't be
a large issue. Someone who phishes your password over email would empirically
be unlikely to hack your phone.

~~~
chimeracoder
> However, it still remains that the secret is sitting in plain text on a hard
> drive on the phone. If you unplug/unsolder the hard drive, you could just
> read it, like a PC.

"In plain text"... on a disk that is fully encrypted. Full-disk encryption has
been available in Android for several years, and required for almost all of
that time.

------
bascule
As a Yubikey fanboi since 2013, who was very excited about the prospect of
using it for airgapping GPG and SSH keys circa 2014, 2018 me says: "you almost
certainly don't want to do this"

Let's start with SSH. It's just plain unstable. If you try to set this up, you
WILL have constant stability problems. I can assure you I have both personally
experienced them and asked several other people who have attempted it to
confirm that they too have various timeouts or other errors.

One alternative is PIV. PIV is even more of a pain in the ass to get set up,
and has similar stability problems.

If I have a prescriptive recommendation for SSH, set up Duo for 2FA and use
Yubikey-AES in "long press" mode (putting the key in slot 2). This gives you a
strong hardware-backed authentication factor and protection against "Yubispam"
(i.e. accidental credential leakage, a problem more severe than most would
consider it)

As for GPG, well... GPG is a tire fire. I also went through the Yubikey GPG
PIN bypass (not their fault, but since Yubikeys cannot be field patched, this
involved physically rotating every key, which Yubico replaced for free, but
still). GPG suffers similar random faults, and gpg-agent can die in a fire,
but at least unlike SSH you're probably not using it as frequently. Still,
getting things set up is ridiculously arcane, thanks to gpg being a byzantine
tool and the crazy mutable state nature of ~/.gnupg

If you end up attempting to replicate this sort of setup, I can bet you
dollars to donuts you will wind up asking yourself "Why did I think this would
be a good idea?" after a few months

~~~
jlgaddis
I've been using this every day for about 2.5 years on each of the three
machines that I use daily (each with its own Yubikey).

I sign anywhere from zero to 20 commits a day (providing my -- very long --
PIN each time) and open probably 200+ SSH sessions every day.

Once I've configured it on a new machine (e.g., I recently moved from Arch
Linux to Fedora on these three machines), I have zero problems with it. There
is no "unstable" issue for me at all.

Judging from my experiences as well as those of my siblings here, I have to
wonder if perhaps "you're holding it wrong".

 _ETA:_ You will almost certainly run into trouble if you use Gnome (or, more
specifically, gnome-keyring). I use XFCE everywhere, though.

~~~
bascule
I suppose one notable delta between our environments: OS X (me) versus Linux
(you, ostensibly)

~~~
jlgaddis
FWIW, I have a MacBook Pro here that I've used it on as well. That was the
primary machine I used all day every day until I built this workstation about
a year ago. Nowadays I don't use the MBP very often at all, but I did just go
check and, yep, it still works on there too.

~~~
bascule
"Works" in a one-off trial or with daily use? What I'm talking about is an
unacceptable failure rate in the course of daily usage (by which I mean
failures at least once or twice a day, sometimes considerably worse, over the
course of establishing several dozen SSH connections daily)

If your OS X daily driver setup is truly stable, can you share all of the
details? What OS X version? Yubikey model? GPG version? OpenSSH version?

I know at least a dozen people who have shared my experience so if there is a
magic path to stabilizing it, I'm all ears.

~~~
jlgaddis
> _" Works" in a one-off trial or with daily use?_

It worked with daily usage from the time I set it up (shortly after buying
that particular MacBook Pro, in October 2016) until the time I quit using that
machine all-day every day (c. December 2017). In addition, it worked on the
previous MacBook Pro I had as well.

It still worked when I spent five minutes on it earlier today. Obviously,
that's not any extensive testing but I have no reason to believe it has
somehow broken itself in the time it's been sitting on a shelf, turned off.

I'll grant you that it's certainly not the easiest thing to get up and
running... but I also know that it can be done and that it can work quite
well. TBQH, if it had been that much of a pain in the ass, I wouldn't have
bothered.

FWIW, this is a mid-/late-2016 MacBook Pro, running 10.12.something (never
updated it to High Sierra), with a Yubikey Neo. GPG came from homebrew, IIRC,
and SSH as shipped with the OS. I'm on mobile at the moment but I'll try to
remember to go back and check all the version numbers and such later, if
you're truly interested in them.

It sucks that you experienced so many issues with this but I think there's
enough anecdotal evidence here to show that this _can_ all be made to work --
and work reliably.

------
krrrh
An alternative to this is [https://krypt.co/](https://krypt.co/) which
generates keys on your phone’s secure element/enclave and communicates with
your laptop via bluetooth. It has a straightforward script to copy another
public key from a backup phone to all your authorized servers, and the UI is
excellent for signing git commits and authorizing ssh sessions. Doesn’t yet
support U2F.

~~~
tzs
From their FAQ:

> Can I backup my private key?

> Backing up your private key reduces its security to the security of the
> backup. We do not currently support backing up or extracting your private
> key. In the future we may add key splitting among team members or
> transferring your private key directly to a new phone.

All my data that the private key would be protecting access to is backed up,
so I've ALREADY bought in to the idea that my security is bounded by the
security of my backups. It is not clear to me that not letting me back up the
private key actually does anything to help my security.

In fact, it may weaken it. Their FAQ says that if I lose my phone what I'm
supposed to do is remove my public key from all my accounts, get a new phone,
install Kypton on it, generate new keys, and put the new public keys on my
accounts.

To do this, I have to have a way to access those accounts without using my
private key. That means my security is bounded by the security of my non-
Krypton access method.

If my non-Krypton access method is strong, that means I've got to be set up to
deal with strong non-Krypton secret management...but if I have to do that
anyway what do I need Krypton for? I can just manage my primary access method
secrets myself too.

Also, what if the site requires two factor for the alternate access method?
I'm probably going to be using my phone for that...but remember we're talking
here about the case where I lose my phone, so I lose both my primary access
(Krypton) and my secondary.

~~~
thisacctforreal
Note that on iOS, Krypt supports key generation using the Secure Enclave on
the iPhone 5s (Sept 2013) and newer. In those cases it's impossible to extract
the private key without finding a zero-day in the Secure Enclave coprocessor.

From "Other uses for Touch ID and Face ID" in
[https://www.apple.com/business/docs/iOS_Security_Guide.pdf](https://www.apple.com/business/docs/iOS_Security_Guide.pdf)

"App developers can do the following: [...] Generate and use ECC keys inside
Secure Enclave that can be protected by Touch ID or Face ID. Operations with
these keys are always performed inside the Secure Enclave once it authorizes
their use."

edit: This page has more details [https://krypt.co/docs/security/privacy-
policy.html](https://krypt.co/docs/security/privacy-policy.html)

------
lrvick
I feel the author missed a critical step.

You want to enable user interaction flags to defend against someone with
remote access to your machine.

    
    
      $ ykman openpgp touch aut fix
      $ ykman openpgp touch enc fix
      $ ykman openpgp touch sig fix
    

This will require the yuibikey be physically touched for each sign/decrypt/ssh
operation which while simple is something a remote attacker can't perform.

For more detailed notes from me deploying commit signing and ssh via yubikey
at three orgs see: [https://github.com/lrvick/security-token-
docs](https://github.com/lrvick/security-token-docs)

* Edit: you want to use "fix" instead of "on" to prevent an attacker from just turning it off again.

~~~
jlgaddis
Instead of using those backticks (which don't work here), indent each line by
two spaces. It'll render like this:

    
    
      $ ykman openpgp touch aut fix
      $ ykman openpgp touch enc fix
      $ ykman openpgp touch sig fix
    

_Edited after parent 's edit: s/on$/fix/g_

~~~
lrvick
Fixed, thanks.

------
sufficient
On Android, we provide the OpenPGP implementation OpenKeychain that now also
supports an impressive list of Security Tokens ([https://github.com/open-
keychain/open-keychain/wiki/Security...](https://github.com/open-
keychain/open-keychain/wiki/Security-Tokens)). In our newest release, we also
support YubiKey 4 over USB-C, which is a great alternative to NFC (which is
only support by YubiKey NEO).

Regarding SSH: We submitted a pull request to ConnectBot. You can try it out
if you like:
[https://github.com/connectbot/connectbot/pull/567](https://github.com/connectbot/connectbot/pull/567)

~~~
bergie
Out of curiosity, can software running in Termux (SSH, gpg, etc) talk to the
yubikey?

------
kojiromike
Using a sc like yubikey is great for security, but has performance
implications for parallel tasks like salt-ssh across a bunch of hosts. Yubikey
can only handle a single thing at a time, and is a touch slow, so if you are
using salt-ssh to run a command on multiple servers, and if that salt-ssh
happens to use GPG to decrypt pillars, then you're going to be waiting
hundreds of times longer than you would using the vanilla, parallelizable ssh
agent and scdaemon-free gpg-agent.

~~~
pastage
I use GPG signed tar balls for that, mostly it's just to run scripts on
multiple servers, but also useful for file transfers. You still have to fix
secure transfers between hosts but you do not authenticate the connecting
clients, but your client just need to verify host keys to protect against
MITM. Works on pretty large installations.

I started doing it like this when I only had Debian machines, and just used
apt and Deb archives, but I never could find the time to hack Apt to be a
perfect fit for it and it ended up being hell on other OS.

------
drdaeman
On a tangentially related note - I wonder, are there any OpenPGP Cards with
EdDSA support with a "true" tamper-resistant HSM?

Gnuk-based tokens (FST-01, Nitrokey Start) support Ed25519 keys, but while
there is no obvious security holes (i.e. debugging is disabled etc), they're
most likely not safe if left unattended in hands of an untrusted third party.

~~~
wyager
Pretty sure the Ledger Nano S meets your criteria, but I gave up using it as a
PGP card after some seriously questionable issues like the fact that pinentry
would always ask for my PIN on the host machine even though I had it set to
only ask on the “card”. It’s just a big mess all around. Same thing with FIDO.
It only seems to work in chrome even though Firefox theoretically has support.

~~~
Shoothe
Firefox supports the FIDO U2F spec to the letter while Chrome requires legacy
polyfill script that doesn't use the same exact API. So it's possible to
support both but it's not as straightforward as it should be.

------
urza
Btw you can also do SSH, GPG and 2FA also with Trezor, which has the advantage
that for all functionallity you can have a one "24 words" seed backup, from
which everything is determined. Oh and you can of course use it as bitcoin
wallet :)

SSH: [https://doc.satoshilabs.com/trezor-
apps/sshagent.html](https://doc.satoshilabs.com/trezor-apps/sshagent.html)

GPG: [https://github.com/romanz/trezor-
agent](https://github.com/romanz/trezor-agent)

2FA: [https://doc.satoshilabs.com/trezor-
user/u2f.html](https://doc.satoshilabs.com/trezor-user/u2f.html)

------
insomniacity
All of you guys using a Yubikey, seriously, in production - do you have
another one prepped, tested and sitting in a safe?

I just feel I have to look at the price, and order two, or it's just a toy.

~~~
alanpost
We use Yubikey for our production systems and yes: every operator has two keys
that have been configured and registered in our access database.

We decided though not to make our backup keys hot. It's a manual operation to
enable it. The risk that everyone could simultaneously lose their key was
lower than the risk of a backup key being lost and then used--since a person
isn't likely to routinely check on their backup keys the later problem may go
undetected for some time, whereas you know the day you lose your primary key
and must report that situation anyway.

------
acdha
If the author sees it, `enable-ssh-supprt` in the SSH example is typoed.

~~~
gehaxelt
Hi,

thanks, I've updated the post!

------
thomashabets2
I prefer a physical presence proof for SSH instead of this proposed solution:

[https://blog.habets.se/2017/10/Yubikey-for-SSH-after-the-
inf...](https://blog.habets.se/2017/10/Yubikey-for-SSH-after-the-infineon-
disaster.html)

(long version here: [https://blog.habets.se/2016/01/Yubikey-4-for-SSH-with-
physic...](https://blog.habets.se/2016/01/Yubikey-4-for-SSH-with-physical-
presence-proof.html))

Before that I used the method described in the article, blogged at
[https://blog.habets.se/2013/02/GPG-and-SSH-with-Yubikey-
NEO....](https://blog.habets.se/2013/02/GPG-and-SSH-with-Yubikey-NEO.html)

~~~
Shoothe
The blog post you linked to is using the PIV applet on Yubikey. You can do
touch based OpenPGP operations on Yubikey too:
[https://developers.yubico.com/PGP/Card_edit.html#_yubikey_4_...](https://developers.yubico.com/PGP/Card_edit.html#_yubikey_4_touch)

~~~
Xylakant
Only for YK4, the old neos and YK3 don’t seem to support that. (Makes me
consider buying a YK4 right now)

------
Tharkun
I lose things. Frequently. Key fobs have fallen off my key chain. Someone once
snail mailed me a flash drive which I'd lost (and which contained a single
scanned invoice). I don't like physical access tokens. House keys are kind of
a necessary evil (and I'm paranoid of losing them). But that's as far as I'm
willing to go. Everything else can just live in my head. Including the strong
passphrases to various SSH keys, GPG keys and whatnot.

For anything I don't want to remember, I use pass.

~~~
jlgaddis
I've, fortunately, never lost my keys -- including my Yubikeys -- but I keep
spares just in case I ever do.

When Yubico shipped me two new replacement Yubikeys (recent RNG issue), I just
tossed them in the safe. I've also got a USB flash drive in there (in a
tamper-evident bag) with a LUKS-encrypted filesystem that contains a backup of
my GPG keys. I've got another such USB flash drive safely stored at another
location too.

------
GunniH
I use the YubiKey for SSH auth on several servers but didn't go the GPG route.
I opted for the challenge SSH mode using PAM.

    
    
      Using username "gunni".
      Using keyboard-interactive authentication.
      YubiKey for `gunni':
      Using keyboard-interactive authentication.
      Password:
      Last login: Tue Jan  14 14:07:02 2018 from X
      [gunni@box ~]#
    

Works like a charm but I might look into the PGP variation if one of you can
hard sell it to me.

------
beezle
Yubikey is a step in the right direction, but afaik it is still vulnerable at
the pin entry level unlike a dedicated smartcard wtih pinpad reader. Likewise,
gpg-agent, if I understand/remember it correctly, is also subject to attacks
that would not be possible with the dedicated reader+card combo.

------
CraneWorm
I think Facebook uses Yubikey together with ssh for their (internal) 2FA
[https://www.youtube.com/watch?v=pY4FBGI7bHM](https://www.youtube.com/watch?v=pY4FBGI7bHM)

------
innagadadavida
There is a module to make it work with touchbar MBPs fingerprint readers. Not
sure if this is custom to our work or something that ubikey provides. It’s
pretty seamless and much safer than using just a ubikey.

------
cjbprime
Huh, is using SSH on a GPG key safe? Can't the server trick you into signing a
"challenge" that is actually a meaningful statement?

~~~
jopsen
No,

1) GPG has built-in support for this; presumably they are smart

2) GPG has an authenticate bit, which is required on the key in question.

3) You can (and typically will) create a separate sub-key, with the
authentication bit set.

~~~
akerl_
The "authenticate" bit isn't really material here. GPG keys are, at their
heart, just asymmetric private keys (most typically RSA these days, but there
are plenty of other options). The authenticate/sign/certify bits are flags
that client tools use to know which key to pick, they aren't enforced
anywhere.

The reason your auth key is used for auth and signing key is used for signing
is just because most GPG tools are helpful.

It's also worth noting that an ssh agent using agent forwarding exposes use of
all the keys it knows about, not just the one used for the initial connection.
So if you SSH to 1.2.3.4 with "-A", that host has the ability to poke your
agent and ask for any keys it's got loaded up.

The "presumably they are smart" bit is also rather concerning. Being smart is
generally not protection against mistakes. This isn't to say that gpg-agent
allows malicious action, but we should start from a presumption that bugs
exist, rather than just assume they don't.

~~~
jlgaddis
> _So if you SSH to 1.2.3.4 with "-A", that host has the ability to poke your
> agent and ask for any keys it's got loaded up._

I'm sure you know this but just to be clear... if you're using "-A", that host
has the ability to ask for _operations to be performed_ using any keys it's
got loaded up.

It can't just say, "Lemme have all those private keys you got!". That's the
primary purpose of storing them in a separate device -- the actual keys
themselves become inaccessible and aren't exposed. Again, the device keeps the
keys internally and performs operations using them on your behalf.

Besides, in my case, even with an "offline master" key and three subkeys, the
agent still only knows about the authentication key. The others don't get
loaded into the SSH agent. I don't even use agent forwarding in the first
place, but that's beside the point.

------
Zombieball
I believe the following security advisory applies to anyone interested in
starting to use GPG + Yubikey:

[https://www.yubico.com/support/security-
advisories/ysa-2017-...](https://www.yubico.com/support/security-
advisories/ysa-2017-01/)

Seems the recommendation is to ensure you generate GPG private keys off the
YubiKey (if you have an affected device).

~~~
danjoc
All the keys affected are eligible for free replacement. Get a new one if
yours is affected.

~~~
Zombieball
Yes I should’ve mentioned this. Thanks! Love my yubikey and would reccomend it
to others.

------
alexk
Also, check out how U2F works and how to use YubiKey with Teleport/OpenSSH:

[https://gravitational.com/blog/teleport-now-
supports-u2f/](https://gravitational.com/blog/teleport-now-supports-u2f/)

------
Neutrion
for this kind of gadgets to truly win the favor of security-minded folk, first
it has to be durable, which most of the product (include this one) failed to
show.

------
forgotmypw
Too bad that USB extension cord is trojaned...

~~~
jopsen
you still can't copy the key :)

------
nukeop
Yubikey is very useful as a 2FA authenticator. I wouldn't use it for SSH and
GPG. I wish there were more websites that supported U2F out of the box, or
supported using Yubikey as an authenticator without first adding a mobile
phone number, which I don't share on a principle.

~~~
hollander
I have a Yubikey on my keychain, and never use it. I'm still looking for that
application that will make me want to use it daily. I was thinking about using
it to unlock my Mac, hoping this would add to its security after Meltdown and
Spectre. Maybe add a second admin account which would require Yubikey. Then if
that fails, I have another admin account without Yubikey as fallback login.

My main problem is how to handle the loss of the key. Now I have one, but how
do I handle the loss of one or more keys and can I lose access to my encrypted
laptop? Same goes for Lastpass or other password managers where 2FA might be
used. On the other hand, if I have an accident with head trauma and forget my
passwords, what then?

~~~
Shoothe
> Now I have one, but how do I handle the loss of one or more keys

The same way you handle loss of keys to your home, car, etc. - you buy a
second pair. If you're using OpenPGP you can provision them with keys any time
so it's not a problem but if you're using U2F then you better add at least two
to all your services (Yubico has a cheap U2F only key).

~~~
ben1040
Yep. I got multiple U2F keys. One is on my keychain, another is in a drawer in
my desk, and a third is in a safety deposit box at the bank with my other
important documents.

