I know Yubikeys are pretty old hat by now, but I still feel weirded out by relying something like this into a USB stick. I just know I would lose the key at some point locking me out from everything. Of course the solution is to have two keys, but don't really know where I would feel comfortable storing the extra key (also how often do you check that it still works?)
I'm probably just over thinking this and overly paranoid.
You're not wrong, but this is exactly the use case for a USB security stick. The key is in there, cannot be extracted in any way*, can only be "used" (not accessed or copied, just used for crypto operations) while the stick is plugged in, and without it it's impossible to proceed.
It kind of goes without saying that losing the key results in you getting locked out - if there was any other way there wouldn't really be much of a point to the complication of making yourself dependent on a stick.
As a backup, you either have some kind of spare keys in safe storage or reliable access to someone who can restore your access after having identified you.
* in some case you could generate the key beforehand on a computer, and then load it on a stick (unsure about yubikeys though). You should still revoke your key anyway once your stick is lost - as you should assume it could be found and used, sometimes needing only a touch operation rather than a PIN.
> It kind of goes without saying that losing the key results in you getting locked out - if there was any other way there wouldn't really be much of a point to the complication of making yourself dependent on a stick.
> As a backup, you either have some kind of spare keys in safe storage or reliable access to someone who can restore your access after having identified you.
I have two Yubikeys, but I don't consider the second one as "spare" that has to be locked away. I carry one USB-C/NFC key on my key chain. The other is a USB-A Yubikey nano, which is always at home in my desktop's monitor USB port so I can reach it very easily. By using both regularly, I'm more likely notice if one key gets broken or lost.
> * in some case you could generate the key beforehand on a computer, and then load it on a stick (unsure about yubikeys though). You should still revoke your key anyway once your stick is lost - as you should assume it could be found and used, sometimes needing only a touch operation rather than a PIN.
You can do that with yubikeys. You can copy the same secrets to a different key or store them somewhere safe. I considered doing this, but in the end all services that I use allowed to add two keys which seems like the better option. My reasoning was that if I have two identical keys A/B and I loose key A, I would have to immediately invalidate key B too - but before I can do that I would need to:
1. get a replacement key C
2. setup new secrets for key C and store them
3. then log into every service to add the key C and remove key A/B
4. reset key B to use the same secrets as key B
Up until point 3 (which my take a while until I get key C, unless I would always have a third key lying around) all accounts are vulnerable. On the other hand if I have two separate keys with different secrets, I can just remove the lost key from all services and deal with the replacement key later.
>I have two Yubikeys, but I don't consider the second one as "spare" that has to be locked away. I carry one USB-C/NFC key on my key chain. The other is a USB-A Yubikey nano, which is always at home in my desktop's monitor USB port so I can reach it very easily. By using both regularly, I'm more likely notice if one key gets broken or lost.
yeah, this is the way to do it. worrying about losing keys is a valid concern for webauthn where some poorly-configured services might only let you enrol a single key, but we've (mostly) got ssh figured out by now and everything lets you use multiple keys. so register and use multiple keys on a regular basis.
There was (is?) a vulnerability in Google Titan keys (and some Yubico products as well) that allowed cloning of keys (having a physical access is a pre-requisite).
If you lose a key you have to take action as if it were compromised, because there may always be key recovery attacks, but chances are the vast majority of attackers aren't going to build a machine learning, electromagnetic measurement recovery system.
Also the Yubikey NEO that was impacted by this is pretty old, released in 2012 I believe.
> 1. The impacted Yubico Yubikey Neo is an old product no more available for sale. All FIDO U2F Yubico Yubikeys currently available on their webstore are based on a newer secure element from Infineon, and are not impacted by our work to our knowledge.
I actually wish there was an in-between model that supported key extraction.
Let me store my key in a secure, offline, physical device... and extract to clone it when my yubikey is worryingly old.
My threat model does not include physical attacks, but storage of a key on-device or in backups? Or forgetting a password for an encrypted archive? yep.
Yubihsm can do that. Not sure about yubikey. It’s called export wrapped. Here wrapped means the export is encrypted by another key first. The only catch (feature) is that the key must be created with this capability on its initial creation, you can’t export a key that disallows exporting.
The robot arm part of this reminds me so much of StorageTek’s tape drive robots. Man those were so cool to watch wizzing around in their giant tubes grabbing and loading tape drives on demand.
The spare in safe storage has limited value: you have to take it out of the safe to enroll it. This is technically easy to solve (with public key cryptography), but I don’t think FIDO/CTAP/WebAuthn has any ability to do this.
Not sure I follow. Don't you just need to save the public key somewhere, and use that to enroll? Why would you need access to the yubikey itself to enroll?
I’m only deeply familiar with the U2F (legacy) protocol, and such devices don’t expose a key pair usable for this purpose. When you enroll, you need to communicate with the token.
But more generally, this is a protocol issue. You can’t enroll your Yubikey with your browser and then, later, have your browser enroll that key with a WebAuthn-using site. You have to put the key in your USB port at the time you enroll with a website. And you can’t do this if it’s in a safe.
That's a very good question and in my opinion the biggest flaw with almost all new 2FA/passwordless systems. The "best practice" is to get a second yubikey or store recovery codes on paper, but that requires keeping them close to you because you'll need to update your backup on every new signup.
That makes these systems entirely useless at protecting against house fires, signups while away from home, or simply services that are too lazy to support your backup style (looking at you, AWS).
I think what we need is one master key that can be backed up in a offsite location (e.g. safe deposit box, lawyer, parents, trusted friends), and then have all subsequent secrets generated from it, or encrypted with it and stored somewhere publicly accessible.
I think people start with trying to do the best practice too early. Just using one key as your primary authentication adds a lot of security as other authentication methods aren't as routinely exposed. That's enough to get started and makes it easier to think about backups when one is ready for multiple keys.
> Just using one key as your primary authentication adds a lot of security
Yeah, and look just how often people lose or wash their phones or their keys, or how easy it is to break off a Yubikey that is on a keychain (e.g. when a cat pulls on it). Then you are usually royally screwed.
> If you lose your primary method you have to remember the password to unlock your secondary software ssh key..
The post I was replying to was talking about 2FA in general, not just for SSH keys. Many people take the advertisements of Facebook, Google, Twitter et al. to push for 2FA as pure gospel, but completely neglect "worst case recovery" scenarios - and then run into stone walls when it inevitably happens, because FB/GOOG/TWTR don't offer any sort of customer support (other than raising threads on HN, and even that is similar to winning the lottery) and Amazon AWS doesn't offer multiple 2FA keys at all.
The laws of statistics mean that even if something happens only for 0.001% of all users, at the scale of the big tech companies it still hits tens to hundreds of thousands of people, who have no recourse at all and are now completely and forever locked out of their online identity. Simply because they have not known about the failure modes.
We here, who debate on HN, know about the dangers and how to prevent them. But our parents? Our siblings? They do not, and companies push them to extremely irresponsible practices nevertheless. We can't go and claim on the one side (when fighting against surveillance, backdoors etc.) that our online identities and presences are extensions of our minds and should be protected, and at the same time make it so extremely easy for people to lose access to them!
AWS not offering multiple 2FA keys is one of my biggest annoyances, its a service that I feel much have 2FA due to its ability to run up extreme bills, but I also cant setup a backup key in case of loss or failure.
It is a big annoyance but I think most places (once they're beyond a few engineers in size) use federated auth that support multiple keys (Okta, Active Directory, GSuite) for AWS access.
You can also use TOTP and store the secret in a password manager then protect that with hardware keys.
At $JOB-1 we solved this by building a virtual TOTP service that grabbed the MFA secret for a particular AWS account from our internal secrets tool (which itself required MFA and supported multiple users) and used it to generate codes.
Like a fisher taking their account and convincing support they are the real user? You can't really blame fido for the fact that consolidation made a dangerous situation. I'm very happy with my past choices to intentionally lock myself out as a failsafe over a 50/50 chance that it's me who gets an account back.
OK, how often? Seems like a relatively infrequent issue, although at the scale of cell phones it certainly happens "often".
But you aren't really screwed, you can recover your accounts. You still know your password, you likely have an associated email, you may have even written down your recovery codes.
I'm saying that if you have the password and the email address, bypassing 2FA would not be unreasonable, and it's what most services end up doing (for better or worse). Recovery codes are the ideal, of course.
But yeah, this is also why every new Android/iOS device can act as a FIDO2 token - the more tokens people have, the easier it is to recover with a second token vs having to fall back to less safe methods.
>I think what we need is one master key that can be backed up in a offsite location (e.g. safe deposit box, lawyer, parents, trusted friends), and then have all subsequent secrets generated from it, or encrypted with it and stored somewhere publicly accessible.
This is a very good point. Essentially what you are describing here is a certificate authority.
The Yubikey, in this scenario, just acting as an 'offline CA'
It's a very good idea, but requires software being built to accept an authentication hierarchy.
A lot simpler than a certificate authority, actually. There's no need for hierarchy, x509, or anything of the sort.
Take SQRL[1] for example. It's a login system where you scan a QR code with your phone, then your phone derives a private key based on the domain and a master key, and use that to sign a challenge. Every other device (including offline backups) will generate the same private key, and hence give access to the same account.
I sign up for a lot of services when I'm on vacation (local taxi, event and tour guides that now require apps, SIM card contracts, etc). Losing/breaking small electronics is a big risk when traveling, so I wouldn't use Yubikeys for those even if they are supported.
As someone who uses Yubikey for about 5 years for SSH, GPG and O2F, an extra key is indeed the solution I use.
Effectively it means all integrations must support multiple keys, and you’ll have to register both. Of course, this doesn’t work everywhere, such as AWS. In those cases, I typically use my “main” key.
I’d argue that the key breaking due to wear or being lost is less of a risk than human error: just last week I had to enter the admin GPG code for the first time in years, and I forgot it initially, which caused the device to lock itself, and apparently the recovery code didn’t work. Caused me a few hours of stress to get it resolved.
So yeah it requires some discipline. What’s important is that you need to identity the services you absolutely cannot lose access to: in my case it’s my email and password manager. For those two, I properly manage backup codes, regularly test both yubikeys, etc. The rest can all be recovered through email, if it needs to be.
I have a question - do you disable regular OTP 2FA on services you use the Yubikey? I have one too and religiously added it to all kinds of things, but each service allowed me to just skip the yubikey when a regular OTP code was entered, effectively making me not use the yubikey
If you have only one Yubikey, and use it as the only factor of authentication to a website, you'll need to ensure you store the 2FA recovery codes safely. Whereas, if you have both Yubikey and TOTP as factors of authentication, if you lose the Yubikey, you'll still be able to login.
I view that as "Yubikey more convenient than TOTP". You can either use TOTP, or the Yubikey, and it's easier to tap a button than to enter a code.
Not the GP, but I also use YK as a primary auth mechanism and TOTO as fallback.
Since I only use TOTP as fallback, I am much more vigilant if I suddenly get a TOTP prompt. I should never get one, only in circumstances where I explicitly want one. Every other instance is a big red flag. Is that perfect? No. Is it better than TOTP: yes.
>just last week I had to enter the admin GPG code for the first time in years, and I forgot it initially
Now this is scary.
I'm going to reveal some of my opsec but my password manager (pass(1)) does have yubikeys registered but it also accepts my GPG key. So even if I lose my yubikeys I can still unlock all the passwords, otp codes and everything I have in there.
I just can't feel comfortable with any other solution than my head being the final master key.
I use pass also but only with GPG and I feel a bit uncomfortable that I don't know anything about GPG, I don't remember if I set a password there or how to move it to another computer for backup or sync of the stored data in pass.
I think the official recommendation is to store a second yubikey in a safe location.
Personally I just generated my key offline (on a tails livecd) and backed it up to two different LUKS-encrypted USB sticks. One of those is stored at my place and another one at a trusted person, in case my flat burns down or so. The yubikey itself only stores subkeys, my master key stays on said USB sticks.
Been using this setup for about 5 years now and it's been working well for me so far. Once a year, I extend my gpg keys expiration time by using on of the USB sticks.
No. There is no way to push a value for the symmetric key that probably makes the FIDO (thus U2F / WebAuthn) feature work. You can tell the Yubikey to pick a random new one, effectively wiping your key (and rendering any credentials previously minted with it now invalid) but you can't write one over USB and this was I believe intentional.
Solokeys (https://solokeys.com/ - v1, don't think the newer v2 does) have a special firmware version that implements this and allows you to use a custom seed - and as such restore a key from it. It only works on non-resident credentials (most commonly used, as the number of RKs is usually very limited) though.
The firmware is here https://github.com/conorpp/solo-dicekeys/releases/tag/5.0.0
But it's also shipped in the keys dicekeys sells and I think only their app implements the client side of seeding anyway: https://www.crowdsupply.com/dicekeys/dicekeys
Thinking carefully about loss scenarios is really important, so you're thinking about the right things. I used to have my SSH key on a Yubikey for awhile and now I have it in my MacBook's secure enclave guarded by TouchID. In both of these cases I'm not terribly worried about loss because it's almost always the case that loss of SSH access is pretty easy to recover from. In most cases other people on my team also have SSH access and can swap out my key if I lose the Yubikey. In a number of other cases the cloud server doesn't have any/much in the way of irretrievable data. It's just running various software that is usually version controlled with git. So even if no other team member had access it would be pretty easy to spin up another machine to replace the one that I can't log in to, change the domain name to point to the new machine, and terminate the old one.
You're not overthinking it at all. I have two YubiKeys for that reason. I also have a fire safe with some important docs in it (hopefully the yubikey won't melt!). Plus, I'm older, and I'm getting forgetful, and I worry I'll forget my long lastpass master password some day, let alone all my SSH keys. There are real assets tied to my passwords. Fortunately at my age I have a relationship with my estate lawyer, and financial advisor, who has power of attorney so most of that is safe, but I don't think anyone has really figured out how to handle long-term digital assets. In fact, I'm actually working on a side project to do this.
I don't have two keys. I do keep a fallback method like restore keys written on a safe place.
I did find out however that my old Ledger X can do U2F and GPG so I'm trying to learn how to use it. This Ledger was my first first hardware wallet but I got a coldcard which in my opinion is a better bitcoin wallet. I had no idea what to do with the ledger - second hand market for these things are a big nope. I was pleasantly surprised when I found out there are apps that allow the Ledger to perform some of the Yubikey functions.
> but don't really know where I would feel comfortable storing the extra key
So this doesn't really matter, because with enough incorrect PIN attempts the YubiKey will wipe the credentials. Store it somewhere it won't get destroyed, but don't worry too much about theft.
I thought about this when getting my two YubiKeys as well. I have one on my keychain. Sure I can still lose my keys, but I've had that happen probably once in my life so far. The other one is stored in a relatively safe space in my house. It isn't particularly well hidden or anything, just in a spot out of sight that I can easily remember. After a few months of using them it hasn't been as much of a hassle as I originally thought it might be.
I think that might be only half of the solution. Whenever I have to keep two things in sync—like, in this case, two security keys—, it's always been trouble waiting to happen.
What I'd love to see would be some kind of "trust relationship" between two security keys – ie, if I had set up an account with key 1, but tried to access it with (transitively-trusted) key 2, I would be granted access.
I personally store a printed copy of an emergency-only SSH key (ed25519) in a safe, also formatted as a QR code to quickly import it if something goes wrong. The key is short enough to fit within a QR code length limit, and I can quickly scan it to my computer using my 2D barcode scanner.
I just import my `authorized_keys` that I keep up-to-date on my new server when I do the initial setup.
I was thinking the same initially. But I've been using my Yubikey for 6 or 7 years now, haven't lost it, haven't lost the recovery key which you create during initial setup, and it survived three times being machine washed. I don't know your full situation, but I'd say people are generally much better at not losing things than they think they are.
Encrypt the private key with a strong one time password which you print off (multiple copies) and put in safe places.
This is perhaps not ideal perfect security, but ultimately security is a always a tradeoff with usability and losing a physical item probably has greater chances than someone deliberately trying to get your private key.
You can generate keys off-yubikey and store them in a safe encrypted backup somewhere offline/online/wherever.
Then just import those keys into yubikey and use that.
Ideally though you would rotate keys if you lost your yubikey because you never know if the password was compromised or not.
After buiyng a Yubikey and using it for like one year, I now use 1Password to manage all my MFA.
It can work like Google Authenticator (using OTP), except it's not tied to a single device.
Not as safe as Yubikey, but likely a good compromise between security and user stupidity protection.
Also:
- 1Pw blocks itself after a few min without use.
- Installing 1Pw for the first time in a device is a bit more bureaucratic than a simple login.
I really think any MFA needs something to protect users from forgetting stuff to be successful. Even if it's something stupid like going physically to a store. I can't stand the idea that by loosing my two keys I will loose access to all my things and there's no one who can help me.
1Password is super convenient for MFA, but it's really FAKE MFA. You password and the OTP secret are both stored together, in the same vault, guarded by the same password.
If one is leaked or accessed, so is the other.
It only really provide protection against the most basic / passive MITM attacks.
My Precursor† arrived last week, I'm optimistic about the direction the project is going in. Once the ecosystem is fleshed out, we should be able to store secrets with high reliability and deniability, combine this with something like tarsnap and it should be possible to recover everything off a piece of paper, from anywhere, with a fresh device.
If your whole life is on your phone like me, just attach a yubi to your actual keychain (which is stuck to your phone) and then you'll always be thinking about where your phone/wallet/keys/security are all the time.
Then put the second key on your desk. My yubi happens to be annoying to fiddle with since it's on my keychain, so I use the desk one for signing most of the time.
If there's a house fire, you'll have your phone on you. If you lose your phone, you'll have a key at home.
You're missing the scenario where the police take your phone and your electronics (and the yubi on your desk) and have access to all your accounts because of the yubi attached to it, and you're left locked out of everything.
I am often quite baffled by people using only the device.
The whole point of all this is "something you have, something you know".
Yet lots just have passwordless keys for ssh with their yubikey. Completely unsecure, unsafe in examples you cite, and more.
When using ssh keys for login, you should enforce remote/server password requirements and an ssh key. This is trivial to do in sshd_config, and important.
Never trust end users to have passwords on their ssh keys. Always enforce it server side.
I'm a long-time Yubikey user (since they arrived) and I keep my Yubikey on my keychain, with my house keys.
I've a USB dongle at my office workstation (not a laptop, good ol' desktop) and I use Yubikey to store boot decrypt password. I do have a backup.
The anecdote is this: I have to take my keys out of my pocket and then insert Yubikey into the dongle. Naturally - I forgot to take the Yubikey and the keys back, cycled back home (6km away), realized I don't have the keys to my house, had to cycle back, couldn't get into the building, had to call my coworker to come back to let me in.
And I'm glad it happened. For the past 4 years (since it happened), I've muscle-memory when it comes to handling my physical keys and how I use the Yubikey.
Well I've only got one key on the chain, though my wife has a couple of them. Nothing too cumbersome, plus I have a strap that's useful for pulling the phone out of my pocket.
As others pointed out, you just add another factor (TOTP) or print backup codes.
Or just have another way to sign in. Generate random password for root user, store it in your password manager, disable root login via SSH and... whenever you find your user locked out, log via root via console. In a corporate environment, you could audit and alert whenever root logs in as it should be only "recovery" user.
Keeping an extra key stored away works well enough.
IF my primary key gets lots, I'd hope the one backup one won't suddenly fail that same day -- if it does, then there's a problem.
The annoying bit is having to add all 2FA tokens to the backup one -- which is tricky if you want to store if off-site, since you need to bring it in every once in a while to add all the new 2FA secrets to it.
Am I living too dangerously? I keep two U2F keys enrolled, one as a backup in a safe place, the other on my keyring. And for sites that still use passwords, in-browser password manager works well for me.
What kind of key-breaking do you think can still screw me over?
That’s what makes these keys so secure. Most people I know keep one on their person (keychain), one in a locations they have easy access to (hidden at home), and one off-site. You still have a password as the first line of defense so don’t overthink it.
My thinking is the same. That's why I, in addition to the second USB stick, also have a plain-text copy stored on paper in a safe. EC keys are even short enough that you don't have to involve a printer in the process.
I haven't kept track of these, but are there no solutions to have a master key that one can create any number of keys from? And where that would not require one to update all hundred services using it.
You obviously keep backups (either in form of another YubiKey or backup codes). That's just common sense, you don't only have a single house key either right?
In the physical world I can call a locksmith. For work related MFA I can call my manager / IT. For personal accounts I do stress a bit about locking myself out - obviously have backup codes etc, but unfortunately I'm not sure that I could regain access to say GitHub or Google accounts if my backups failed (hopefully never need to find out)
I keep my backup key in a drawer with a bunch of papers and records and shit. It's also where I keep my 2FA backup codes, and a few other decryption keys.
> As of OpenSSH 8.2 (Feburary 14, 2020) you are able to store an SSH private key on a yubikey! Here's how to do it.
Many systems still don't have OpenSSH 8.2 (Windows 11, older debian stable, etc). For those, another solution is to use the PGP applet of the YubiKey, which exposes a regular RSA key.
You can jump to the SSH sections if that's all you're after.
There's a missing piece for Windows, since the agent coming with WinGPG won't be reachable by SSH. Some guy on GitHub put out a workaround, but I can't find it right now.
A bit pedantic, but what's currently "Debian stable", Debian 11, has OpenSSH 8.4. The previous release, Debian 10, has OpenSSH 7.9, but it is no longer called stable (instead, it's sometimes called "oldstable").
You can use a GPG key stored on a YubiKey with openssh, but with some caveats:
1. gpg-agent must act as your ssh-agent (which means ssh-agent should be disabled and replaced by gpg-agent).
2. If using `pinentry-curses` (YubiKey usually permits access to the contained GPG key via the use of a pin), you must have `export GPG_TTY=$(tty)` (or your shell's equivalent of setting the GPG_TTY environment value to the output of `tty`).
3. You can fetch the public key of your GPG key with `ssh-add -L` (gpg-agent must be acting as your ssh-agent, and the YubiKey with the GPG key has to be plugged in).
4. You must have the line `enable-ssh-support` in your `$GNUPGHOME/gpg-agent.conf`.
I used a guide[1] to set up a GPG key on to a YubiKey, and for those who don't want to use GPG, the guide also has a section[2] about just using an SSH key as well.
I am using this setup for a while now and would like to tell everyone about an advantage in contrast to the 'resident key': You can push a single, identical key to two YubiKeys, making it easier to recover.
Resident keys are (partially?) created on the hardware token and thus can't be replicated. The GPG keys can be pushed to a couple of YubiKeys before you delete them forever (or keep a paper backup somewhere safe).
I made my own CA for this because nothing else could provide transparency regarding certificate issuance (whether an attacker issued a "spare" backdoor certificate)
Yubikey Manager is not needed to use ed25519-sk keys. They use only FIDO U2F functionality, so cheaper USB keys ($29 for a Yubico Security Key USB-C NFC vs $55 for the full Yubikey 5C NFC).
They are thus not limited to Yubico's proprietary functionality controlled by Manager, which has a wider attack surface than I am comfortable with, and are not limited to platforms running the Yubikey Manager software (e.g. on OpenBSD). Since the key has never been outside the USB enclave, there is no way it could have been surreptitiously copied, e.g. if there was a rootkit on the machine where the key was generated before copying to the Yubikey.
I suggest testing it yourself in any case, I don't think this article is correct in this. I did try it in the past with Google Titan and not a Yubikey and I could be wrong.
EDIT: `-O resident` might be what is doing it though, I wasn't aware of this option.
Non-resident keys will basically give out the private key encrypted with a static master key as the key handle and thus support an unlimited number of keys. If you lose the key handle, then the key is gone. That's probably what you were experiencing with your Titan.
Thanks for sharing the article. I followed it and it was very simple to set up.
In the past, I postponed setting this up after I encountered issues. I tried to run "ykman", but it seemed to fight with "yubioath-desktop". It was tricky to debug and I ended up rebooting. I think the reason was that I installed "yubioath-desktop" using snap, which runs "pcscd" as a snap service, and "ykman" wants to start the "pcscd" system service.
Either case, for this tutorial, I skipped the part running 'ykman'. Basically the only commands were:
Unless I've missed something, SSH keys stored on Yubikeys are still hampered because you aren't allowed to a touch policy of "touch never".
Imagine needing to touch the Yubikey with each "git pull" or using Ansible to operate over SSH on a dozen servers in parallel, and needing to touch the Yubikey once for each server.
What I would love, and it has not been supported (I was basically told “Go away, kid. Yer bodderin’ me!”, when I suggested it to AgileBits), is the ability to store the local 1Password vaults onto a separate volume from the main one.
I have a small encrypted disk image that I mount, after booting my computer. A YubiKey would be similar. I use this to store my really critical stuff. I don’t back up the mounted disk, but do back up the encrypted image.
That’s different. The shared hosted vault is better (and works great). I’m talking about a “set and forget” version, where 1Password doesn’t work at all, unless the volume is mounted.
I tried using symlinks or aliases, but that did not work. 1Password simply created a new vault.
but wait a minute... this is just storing the private key material on the yubikey like any storage device and it is loaded and copied right off every time you use it, right?
doesn't that defeat the point of using a yubikey where the private key itself is never read from the device during authentication?
Author of the article here. From what I understand it puts the private key material on the Yubikey itself and then during the signing part of SSH authentication the SSH client asks the yubikey to do the signature. The private key never leaves the device.
interesting, just read through the release notes. pretty cool.
i think a small discussion of this (and how the agent/key handles/resident mode work) would make an excellent addition to the blog post. it was very clear how to set it up, but left me with questions as to if i should...
in practice i would wonder about backup authentication methods and key rotation....
No, the private key never leaves the YubiKey. SSH and GPG talk to the YubiKey as if it were a smartcard - data is send to the key to be signed or encrypted.
Thanks - "ssh-add -L" talks to the ssh-agent and asks what keys are loaded. That shows all keys including keys from the yubikey and from the local filesystem.
I am looking for a command that shows what's on the yubikey.
From what I gather, if the command from the article is run: "ssh-keygen -t ed25519-sk -O resident", the key is stored in a FIDO2 slot.
If that's the case, my question is how to show what is in the FIDO2 slots and how to delete them?
> This should work on other FIDO keys like Google's Titan, but we don't have access to one over here and as such haven't tested it.
For my trusty HyperFIDO Mini (usb id 0x2ccf:0x0880) this doesn't work, though it's rather old (1st gen) and maybe they refreshed it to support this. ssh-keygen fails with "Key enrollment failed: requested feature not supported". I wanted to replace it with a USB-C (& maybe NFC) device anyway, so seems like a good opportunity.
The feature causing this is -O resident which tells the device, "Hey, you need to remember these credentials" (ie they are resident on the device).
For WebAuthn this enables "usernameless" login. You rock up to a random PC anywhere in the world, go to example.com, just click "Sign in", and your authenticator is like, "Hi example.com, according to my records I am archi42, user 123456-ACBDE-123 and as proof here's a signature made with my unique private key" and the site checks its database and signs you in. Convenient and fairly secure (most devices with such a feature expect a PIN, or a fingerprint, or some such factor beyond "something you have" in the form of the authenticator itself).
For SSH, this means the magic file that makes SSH with FIDO work can be regenerated on another client machine by just asking it to spit out the credentials.
Chances are your device does not have this feature, usernameless login on the web is rare, so few people need this, and of course it's a considerable extra hardware implementation burden. Yubico products have it though, as do some others, and the phone implementations (iPhone, newer Android) likewise.
If you mostly use the same machines (laptop, maybe a desktop) for SSH, the resident feature isn't important, just don't write "-O resident" and remember that although they aren't a security feature the resulting files are unique and if you don't have them you can't log in. If you regularly use different machines for SSH login because you're say, a roaming technician logging in to physical hardware on site or you insist on travelling very light, then it's very valuable and worth upgrading to get the resident feature.
Thanks, I appreciate the effort you put into the answer; though I know how ssh keys work and the basics about FIDO as well ;-)
I got the hyperfido 5 years ago and doubted they're still selling the same hardware today. I exchanged a few mails someone from their C-suite back then on the topic of using the keys for SSH, and it wasn't easily possible back then (also: he seemed very nice [cue Canada meme], so I didn't want to spread falsehoods about the company on HN). Actually I checked right now, and their current offerings seem to support FIDO2 (also: the model number & name changed slightly). So I suppose their current generation should work.
//edit: ah, your pointer was still worth the effort. I tried non-resident and ecdsa-sk works with my key (but not ed2219-sk). I still need a new key because I want to have a resident key :)
I tried ed25519-sk keys last year, but abandoned them when GitLab wouldn't recognize their public keys. It seems that as of 3 months ago GitLab has added support (https://gitlab.com/gitlab-org/gitlab/-/issues/213259) so I should give them another try.
The problem with this approach is that the `-sk` keys need to be supported server-side (I'm not sure if that support goes beyond including them in a list of recognised key types, but it doesn't matter).
As a result, lots of systems that are not bleeding edge still don't accept them, for example Gerrit.
The support is substantially more than "including them in a list of recognised key types" because the FIDO device is deliberately unwilling to do anything except emit FIDO-style signatures, so you need to understand those signatures and verify them.
On the other hand, probably we should have learned by now that even apparently trivial verification steps are too easy to get wrong (or plain omit) and so you really want to delegate all of this work to just one implementation which was actually written by people who know what they're doing and, preferably also formally verified as correct since people who "know what they're doing" still make far too many mistakes. Thus, maybe there shouldn't be so many independent (and likely in some cases, wrong) implementations of this check.
> such as the Tongues you received as a kid when you were forced into learning the bible against your will
Wait, what? My wife stopped going to Awanas when some leader told her she was going to hell for not learning the Bible verses. Later I learned that her father was pissed off about the whole situation.
I dated a charismatic christian who did the whole laying-hands on thing and speaking in tongues as a kid. Weird stuff. But not any weirder than any other religion system comparitavely.
Wait is generation on the host? Nonono you generate a GPG key on the key then export the public key and derive the SSH key. These instructions are wrong the host never should store the key even if airgapped
Are there any best practices on using one of the "-sk" key types and authorizing usage with your security key, vs. storing the whole ssh key on the security key?
OT: what kind of date format is used in the article? It says „M05 27 2022“ and I have not seen that before. Does M05 mean May-05, so basically saying may-may?
I'm probably just over thinking this and overly paranoid.