[HN Gopher] How to Store an SSH Key on a Yubikey
___________________________________________________________________
How to Store an SSH Key on a Yubikey
Author : kadenwolff
Score : 265 points
Date : 2022-05-30 06:51 UTC (16 hours ago)
(HTM) web link (xeiaso.net)
(TXT) w3m dump (xeiaso.net)
| enasterosophes wrote:
| Something else that is quite nice is that you can switch to
| certificate auth and use your yubikey to protect an ed25519-sk
| certificate authority.
| endre wrote:
| this.
| stingraycharles wrote:
| How does that work, do you know a good tutorial for this?
| enasterosophes wrote:
| Look for a tutorial on ssh certificate auth, and use
| ed25519-sk keys for the CA.
| dnet wrote:
| I made my own CA for this because nothing else could provide
| transparency regarding certificate issuance (whether an
| attacker issued a "spare" backdoor certificate)
|
| - source code: https://github.com/silentsignal/zsca
|
| - my talk about the design and results:
| https://pretalx.hsbp.org/camppp7e5/talk/D3E9HN/
| Diti wrote:
| But PIV only supports keys up to 2048 bits. :<
| enasterosophes wrote:
| I didn't say anything about PIV. The article I was replying
| to is talking about sk keys, and so am I.
| veganjay wrote:
| 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: ssh-
| keygen -t ed25519-sk -O resident ssh-add -K
| nextlevelwizard wrote:
| 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.
| gspr wrote:
| 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.
| tooltower wrote:
| 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?
| NavinF wrote:
| 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.
| WhyNotHugo wrote:
| 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.
| exabrial wrote:
| Any system with a backdoor can be exploited. Keep a large
| number of spare keys that are revokable instead.
|
| Given my "threat model", I don't need a lot of security, so
| that's one on my person, two other places that are in tamper
| evident containers.
| stingraycharles wrote:
| 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.
| aborsy wrote:
| You pull your GPG key from offline backups, reset the applet
| and load it again.
|
| The same Gpg key can be used for SSH too.
|
| You can generate keys inside Yubikey, but you also have the
| option of bring your own key, which surely you keep safe
| offline.
| smartbit wrote:
| Which password manager do you use that supports Yubikey?
| 5e92cb50239222b wrote:
| https://keepassxc.org
| lalopalota wrote:
| Bitwarden's paid plan supports yubikey.
| infini8 wrote:
| As does Vaultwarden - the self-hosted unofficial version
| of Bitwarden
| INTPenis wrote:
| >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.
| krzyk wrote:
| 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.
| INTPenis wrote:
| Yeah gpg is a big hurdle. My suggestion is to learn about
| subkeys. Create subkeys for everything you want to do.
|
| That way you have one main key that can revoke subkeys,
| subkeys do everything like access to files, emails,
| passwords.
| Hackbraten wrote:
| > Of course, this doesn't work everywhere, such as AWS
|
| I've worked around that by creating one IAM user per Yubikey.
| artdigital wrote:
| 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
| rgoulter wrote:
| 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.
| cuu508 wrote:
| WebAuthn is more convenient but also more secure. You
| don't have to be as vigilant when checking what URL your
| browser is pointing at.
| Xylakant wrote:
| 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.
| staticassertion wrote:
| 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.
| samatman wrote:
| 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.
|
| +: https://www.bunniestudios.com/blog/?p=5921
| BoppreH wrote:
| 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.
| ratg13 wrote:
| > _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.
| BoppreH wrote:
| 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.
|
| [1] https://www.grc.com/sqrl/sqrl.htm
| lalopalota wrote:
| For signups away from home, use the key you have then add the
| second when you get home.
| BoppreH wrote:
| 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.
| yakak wrote:
| 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.
| mschuster91 wrote:
| > 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.
| nijave wrote:
| >or their keys
|
| How often do people actually permanently lose their keys
| (besides just misplacing them or leaving them somewhere
| and getting them back)?
|
| I'd saying losing keys (house key, car keys) is fairly
| rare.
| marcosdumay wrote:
| How often have you had a flash drive that stopped working
| for some reason?
|
| Physically losing the keys isn't the only way to lose
| them.
| staticassertion wrote:
| 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.
| mschuster91 wrote:
| You can't login without the second factor and only the
| password because that is literally the entire point of
| having a second factor.
|
| You should not be able to reset a 2FA token purely by
| having access to the target's email (or SMS) account in a
| halfway decent system.
|
| Your only hope will be the recovery codes but well, how
| many people actually read the fine print on these?
| staticassertion wrote:
| 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.
| yakak wrote:
| Sounds like FUD to me. If you lose your primary method
| you have to remember the password to unlock your
| secondary software ssh key..
|
| Possibly remembering a password is a huge crisis but I
| had that crisis before using tokens, i.e. returning to my
| work desktop after a vacation.
| mschuster91 wrote:
| > 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!
| philderbeast wrote:
| 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.
| packetslave wrote:
| 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.
| nijave wrote:
| 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.
| yakak wrote:
| > something happens only for 0.001% of all users
|
| 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.
| xvector wrote:
| > 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.
| drakonka wrote:
| 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.
| phaer wrote:
| 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.
| aborsy wrote:
| No need for LUKS usb. Gpg stores private keys encrypted with
| a password.
|
| At that point, you can store the encrypted key anywhere.
| phaer wrote:
| Ah yes good point for the gpg key itself, but I store a few
| other important secrets there as well ;)
| beagle3 wrote:
| Does this also work for the WebAuthn / U2F / TOTP use cases,
| or just the PGP/PIV/SSH ones?
| tialaramex wrote:
| 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.
| beagle3 wrote:
| Thanks. I will wait until it's actually possible to
| create back up webauthn keys (rather than enlisting two
| keys with every service).
| opliko wrote:
| There is actually at least one fido2 device that supports
| backing up (mostly), based on this spec from Dicekeys
| https://github.com/dicekeys/seeding-webauthn
|
| 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
| m-p-3 wrote:
| 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.
| tjoff wrote:
| 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.
| macrolime wrote:
| I think this can do that
|
| https://github.com/Logicwax/gpg-hd
| jve wrote:
| 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.
| mightybyte wrote:
| 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.
| lordnacho wrote:
| 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.
| zmxz wrote:
| 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.
| orev wrote:
| Keychain stuck to your phone? I don't think I've ever seen
| anyone with a setup like that. Sounds incredibly annoying.
| lordnacho wrote:
| 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.
| bbarnett wrote:
| Wait, I read that quicky in your prior post. I thought
| you meant a _software keychain_.
|
| If you ask me, drilling a hole in your phone will
| invalidate the warranty...
| groffee wrote:
| 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.
| bbarnett wrote:
| 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.
| izacus wrote:
| 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?
| mnahkies wrote:
| 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)
| chewz wrote:
| My Yubikeys (main and spare) are attached to keychains with
| AirTags....
| r00f wrote:
| 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.
| pid-1 wrote:
| 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.
| WhyNotHugo wrote:
| 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.
| jopsen wrote:
| Most providers also let you create recovery codes. Or signup
| for TOTP which gives you a QR code.
|
| Print those out and store them somewhere. Then if you loose
| your yubikey you recover access with those.
|
| If you're too lazy to print them, the just store them in an
| encrypted tarball, using a very long password (and then rarely
| open it).
|
| Having the extra key is also fine, but it means you need to
| have the key around whenever you signup for a new service.
|
| In an ideal world, I would encrypt recovery codes with a
| public-key and have the private key for decoding them buried in
| the back yard.
| dageshi wrote:
| 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.
| mywacaday wrote:
| Out of interest if you lost both, what would you lose access to
| permanently?
| Jnr wrote:
| 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.
| sbf501 wrote:
| 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.
| gruturo wrote:
| 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.
| eximius wrote:
| 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.
| [deleted]
| amluto wrote:
| 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.
| chmod600 wrote:
| 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?
| amluto wrote:
| 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.
| kapep wrote:
| > 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.
| notatoad wrote:
| >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.
| infthi wrote:
| > cannot be extracted in any way
|
| 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).
|
| https://news.ycombinator.com/item?id=25675556
| staticassertion wrote:
| 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.
| ulzeraj wrote:
| 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.
| runiq wrote:
| 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.
| WhyNotHugo wrote:
| Yubikeys (and similar hardware tokens) are a blessing for
| authentication.
|
| I use them for SSH, but also for 2FA on the web, `sudo` and a few
| other items. Wrote about it recently here:
|
| https://hugo.barrera.io/journal/2022/05/07/how-i-secure-my-s...
| bschne wrote:
| 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?
| xvector wrote:
| https://github.com/FiloSottile/yubikey-agent has worked really
| well for me in the past.
| xaduha wrote:
| You don't need this for ecdsa keys, normal ssh agent works just
| fine as in `ssh -A`.
| netfortius wrote:
| It's actually even cooler to store them on a Ledger device
| jazzythom wrote:
| 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
| xena wrote:
| Doing that means I have to use GPG. I am not paid enough to use
| GPG.
| sandreas wrote:
| For those who like to know more details about Yubikeys, I found
| this pretty interesting: https://www.youtube.com/watch?v=INi-
| xKpYjbE
| jve wrote:
| While we're at this - is there anyway for sudo NOT to ask for
| password when logged in via key authentication?
| veganjay wrote:
| Some additional information:
|
| - https://www.yubico.com/blog/github-now-supports-ssh-security...
|
| - https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht...
|
| - https://developers.yubico.com/SSH/
|
| The second link describes the advantages/disadvantages of non-
| resident vs. resident keys.
| gwbas1c wrote:
| > 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.
| spike021 wrote:
| As someone who was in an Awana...club(?) for most of my
| childhood, I never had this happen. That sucks. Some people are
| way too crazy.
| sbf501 wrote:
| 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.
| archi42 wrote:
| > 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.
| tialaramex wrote:
| 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.
| archi42 wrote:
| 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 :)
| a-dub wrote:
| 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?
| xena wrote:
| 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.
| a-dub wrote:
| that's how i would hope it would work, but isn't the key in
| this example getting loaded into the agent?
| zrail wrote:
| The agent is a shim that talks to the Yubikey.
| a-dub wrote:
| 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....
|
| but otherwise all in all pretty cool.
| sbf501 wrote:
| Can you also include a screen shot of the ssh connection
| process? The article stops abruptly at the most interesting
| part: using the key.
| jordemort wrote:
| 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.
| veganjay wrote:
| Is there a way to show which SSH keys are loaded on the Yubikey?
| (It looks like you can store multiple)
|
| Also, how can one remove the SSH keys from the Yubikey?
|
| I've tried to find articles and SSH on the Yubikey gets very
| confusing as there seem to be so many techniques!
| vletal wrote:
| In the blogpost they give an example of exactly that
| $ ssh-add -L sk-ssh-ed25519@openssh.com AAAAGnNrLXNzaC1l
| ZDI1NTE5QG9wZW5zc2guY29tAAAAIKgGePSwpBuHUhrFCRLch9Usqi7L0fKtgTR
| nh6F/R+ruAAAABHNzaDo= cadey@shachi
|
| Seems like the key is exposed as ssh agent.
| veganjay wrote:
| 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?
| veganjay wrote:
| Found it:
|
| Install ykman: https://github.com/Yubico/yubikey-
| manager#linux
|
| Show FIDO2 credentials: $ ykman fido
| credentials list ssh: 00000000000000000000000000000
| 00000000000000000000000000000000000 openssh
|
| Delete: $ ykman fido credentials delete
| CREDENTIAL
| fmajid wrote:
| 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.
| tazjin wrote:
| 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.
| tialaramex wrote:
| 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.
| moontear wrote:
| 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?
| cgio wrote:
| M for month?
| ikornaselur wrote:
| I guess it's to clear the confusion of, for example, what date
| would "04 07 2022" be, is that 4th of July or April 7th?
|
| "M05 27 2022" seems to indicate that it's in fact MM DD YYYY
| not DD MM YYYY
| Sharparam wrote:
| If only there was some kind of international standard for
| date formatting we could use to get around that issue...
| xena wrote:
| Owner of the blog here. I use the same date format on my
| website as I do on my phone: https://twitter.com/theprinces
| sxena/status/15312403676008529...
| seodisparate wrote:
| 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.
|
| [1]: https://github.com/drduh/YubiKey-Guide
|
| [2]: https://github.com/drduh/YubiKey-Guide#ssh
| NormenKD wrote:
| 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).
| KelvinAnderson wrote:
| jopsen wrote:
| Curious, if you delete the stub in ~/.ssh/id_ed25519_sk, can you
| then recover the key?
|
| Or does the on-the-fly key generation use random bytes stored in
| the stub?
| xaduha wrote:
| 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.
| TimWolla wrote:
| > EDIT: `-O resident` might be what is doing it though, I
| wasn't aware of this option.
|
| Indeed. This will use FIDO 2 Discoverable Credentials /
| Resident Keys. Those are fully stored on-key (but their
| number is limited): https://developers.yubico.com/WebAuthn/We
| bAuthn_Developer_Gu....
|
| 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.
| ChrisMarshallNY wrote:
| 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.
| Raed667 wrote:
| Have you tried using the "export" feature?
| ChrisMarshallNY wrote:
| 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.
| ndsipa_pomu wrote:
| Is it possible to do something similar with an NFC smart ring?
| I'd be much less likely to lose a ring than a Yubikey.
| vladvasiliu wrote:
| > 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.
|
| This guide has worked well for me:
| https://github.com/drduh/YubiKey-Guide
|
| 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.
|
| --
|
| edit: The workaround for Windows is this one:
| https://github.com/rupor-github/win-gpg-agent
| knorker wrote:
| Not to mention all the network appliances in the world.
|
| While this only works for a subset I'll stay with my RSA key in
| PIV mode on yubikey. Works great.
| jve wrote:
| Another solution for windows: The support is already there
| within 8.9.1.0 beta release:
| https://github.com/PowerShell/Win32-OpenSSH/releases
|
| You must then use the SSH installed within 'C:\Program
| Files\OpenSSH\ssh.exe' and not the builtin within system32.
| Denvercoder9 wrote:
| > older debian stable
|
| 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").
| ylk wrote:
| > which exposes a regular RSA key
|
| With newer Yubikeys you can also use ECC PGP keys:
|
| > Support for Elliptic Curve Cryptographic Algorithms have been
| added to the YubiKey 5.2.3 and above firmware.
|
| https://developers.yubico.com/PGP/YubiKey_5.2.3_Enhancements...
| markstos wrote:
| 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.
|
| The feature request I'm tracking is here:
| https://github.com/FiloSottile/yubikey-agent/issues/95
|
| The proposed feature would allow setting a touch policy for the
| SSH key.
| xena wrote:
| If you use SSH ControlMaster sockets, it's not so bad in
| practice. It can be a pain at times, but I think the security
| is worth it.
| nyanpasu64 wrote:
| 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.
___________________________________________________________________
(page generated 2022-05-30 23:02 UTC)