Using a Yubikey for GPG and SSH

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...

This is much more stable for SSH than the article: https://blog.habets.se/2016/01/Yubikey-4-for-SSH-with-physic... (and also has physical presence proof).

I've been using it for years on many machines. It's great. It's worked perfectly.

Yes, the gpg-agent solution proposed in the article (which is what I used before PIV) was less stable. Nowhere near as bad as you describe though.

I don't know about Yubikeys, but with FST-01 SSH (via gpg-agent, essentially same setup as the linked article) just works. Using this for half an year and no complaints.

Sometimes it doesn't immediately see the key after reboot and I need to plug it out and plug back in. I think this usually happens when I dual-boot and switch between different OSes, as same-OS reboots are usually OK. Haven't exactly paid attention, though. I rarely reboot my desktop machine and I don't keep the key plugged into laptops.

Also, very rarely gpg-agent gets stuck and I have to KILLAGENT /bye. But I think that happens, maybe, once in 2 months or so. Docker (just a random example) gives me more headache.

That's very much not my experience. I agree that the setup is harder than necessary and if you get something wrong the errors are not helpful. But once it works, it works. I've been using yubikey with gpg-agent for ssh auth for years and it generally just works. I've not seen the stability problems you experienced.

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.

I've been using a yubikey for at least 3 years on a practically daily basis for signing and decrypting email (all of my emails are encrypted) and for logging into my various servers via SSH on various Linux laptops and desktops, an Android phone (via NFC) and very recently a Macbook running OSX. My experience is nothing like yours. I have never had anything resembling a stability problem.

Are you perhaps reflecting on the OSX experience a couple years ago? Things have really matured since then.

I have deployed yubikey 4 based ssh auth, commit signing, and password management to enigneering teams at 3 companies in the past 2+ years.

The Linux experience has always been solid and as of gpg 2.1+ and High Seirra mostly fixing their smartcard stack, I can say the OSX setup is now quite reliable as well.

For examples for ssh setup see: https://github.com/lrvick/security-token-docs/blob/master/Us...

Aside: I would -not- recommend Duo to anyone. Beyond putting your security entirely in the hands of a third party with unknown internal auditing and security practices, there is no way to disable SMS 2FA for the admin accounts and support has steadfastly ignored requests to allow this to be disabled. This means sim porting + phishing and you cna control a duo admin account. There is also no secure element componet involved with Duo so malware on the phone can bypass it if sophisticated attackers are in your threat profile.

> 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.

This has not been my personal experience at all. I've used this setup (Yubikey as SSH key) for 4 years now, and by "using it" I mean being connected on SSH 24/7, connecting every day, sometimes multiple times, from and to multiple machines. I have a USB drive on which I store a gpg binary for MacOS and Windows, allowing me to easily SSH from any machine.

GPG is a tire fire, I will give you that. But for the small subset of GPG that we need for yubikey+ssh, it can be made to work OK. You just need the latest version of GPG (2.1), have pcsc-lite and scdaemon installed and running, and put "enable-ssh-support" and "use-standard-socket" in your ~/.gnupg/gpg-agent.conf. This is not hard, and can be done in a 100% portable and sudoless fashion.

As for SSH, I'm not sure why you think it's a tire fire ? SSH works really well for its use-case. It might have problem if your internet connection sucks (like on mobile connections), in which case you can and should use mosh, which still works with this exact Yubikey setup (mosh initiates the connection and authenticates over SSH, and then establishes a UDP connection for the rest of the session).

I've been using this setup daily for years, and, I've only 1 problem - annoying as hell - but something I can live with.

Whenever I use the key for U2F, the gpg access to the card will fail until I `killall -9 scdaemon`. I've had this same issue on both Ubuntu, and openSUSE. And yes, the -9 is necessary to actually kill the process and allow gpg to restart it.

As I said, annoying, but I can live with it.

Anyone else experienced this? Anyone found a fix?

When the secure enclave came up in the context of contactless payments at a 34CCC talk, it was suggested outside of Apple as an iPhone vendor, the type of card operation requiring it are avoided by Google and others because lack of cultural and technical buy in from HW devs.

https://media.ccc.de/v/34c3-8965-decoding_contactless_card_p...

I won't buy into iPhones, HNers can flame away. Does this service get me anything as an Android user?

What happens if you lose your phone? What happens if you factory reset?

Does this work offline?

I really liked this but the notification requirement on iOS killed it for me. I can’t remember the exact details but it is (roughly) not possible to suppress authorization request notifications because on iOS notifications are the only way to wake-up a backgrounded application. Net result is a notifications every single time krypt authorizes via your phone. This may not be a problem for many people but it drove me nuts. It is unbearable if you use auto-complete on the command line in eg SCP.

Edit: typos

Edit 2: related issue https://github.com/kryptco/krypton-ios/issues/75

nice service! windows? i know.. but you cant get a used macbook for 50$. kr install didnt work by the way but the debian linux bash cmds worked in the win10 linux subsystem.

How much will this (eventually) cost? I'm hesitant to adopt any new workflow tool without knowing what it's gonna cost me once I'm completely hooked on it.

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.

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

Warning: "fix" is permanent.

(that's the whole point of it)

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

An attacker also must know you admin PIN (required to change this setting), so there is really no need to use "fix" instead of "on". To be able to toggle this off, you must reset your yubikey (paraphrasing the docs).

fantastic, I use password-store on Android, and this would hopefully remove the need for a dedicated pull/push key..

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

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.

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.

Nothing is safe if left unattended. It’s trivial to make a ‘proxy’ RF device that sends your PIN to the attacker and receives whatever data you would expect from your original hardware token.

Sortof. In practice, I have 2 "live" yubikeys per purpose, since I want a USB-A and USB-C set depending on whether my computer is plugged in to the hub on my desk or mobile.

That gives me redundancy in case I accidentally dropped one in a blender or whatever. But also for anything high-criticality (basically anything where losing both yubikeys would lock me out permanently without further backups), I have another yubikey sitting physically-secured. It works out nice, since that's the same approach I was taking w/ "security question" answers and other recovery tokens.

You can generate the keys on a Raspberry Pi or similar, transfer them to the Yubikey, and keep the backup in a safe place.

My Yubikey is provisioned with a SSH key generated on an air gaped laptop running Tails OS (live cd). The master key and subkeys were then saved on a separate encrypted SD card at the same time for backup.

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.

I don't.

All the services I'm using it on require some sort of backup 2FA method, so I simply use an authenticator app (that I have to use anyway since not all websites allow U2F keys) as a backup method.

Never managed far in messing around to use Yubikeys for GPG and SSH. It's nice and all, but U2F keys are useful without it as well.

Hi,

thanks, I've updated the post!

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_...

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.

I leave my yubikey nano in my laptop at all times.

Security is that: (A) usage requires touch; (B) if my laptop is stolen I'll notice :)

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.

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

you still can't copy the key :)

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?

The blue Yubikeys sold as U2F keys can't be used for SSH the way this article suggests; it's talking about the Y4 keys, which are essentially tiny USB HSMs. Y4 SSH isn't a 2FA mechanism; it's a way to keep your SSH key on a piece of hardware where it can't be extracted.

I don't give two craps about do the companies have my phone number or not, so I understand their argument.

Phone numbers are something all people have, so using it as a backup if you lose your Yubikey makes sense.

With that said, I do understand that someone using a Yubikey has probably already thought about "what happens if I lose it" and advanced threats against SMS, but if we want them to be used by everyone, this seems like a nice compromise.