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?)<p>I'm probably just over thinking this and overly paranoid.
> 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.<p>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.<p>This guide has worked well for me: <a href="https://github.com/drduh/YubiKey-Guide" rel="nofollow">https://github.com/drduh/YubiKey-Guide</a><p>You can jump to the SSH sections if that's all you're after.<p>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.<p>--<p>edit: The workaround for Windows is this one: <a href="https://github.com/rupor-github/win-gpg-agent" rel="nofollow">https://github.com/rupor-github/win-gpg-agent</a>
You can use a GPG key stored on a YubiKey with openssh, but with some caveats:<p>1. gpg-agent must act as your ssh-agent (which means ssh-agent should be disabled and replaced by gpg-agent).<p>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`).<p>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).<p>4. You must have the line `enable-ssh-support` in your `$GNUPGHOME/gpg-agent.conf`.<p>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.<p>[1]: <a href="https://github.com/drduh/YubiKey-Guide" rel="nofollow">https://github.com/drduh/YubiKey-Guide</a><p>[2]: <a href="https://github.com/drduh/YubiKey-Guide#ssh" rel="nofollow">https://github.com/drduh/YubiKey-Guide#ssh</a>
Yubikeys (and similar hardware tokens) are a blessing for authentication.<p>I use them for SSH, but also for 2FA on the web, `sudo` and a few other items. Wrote about it recently here:<p><a href="https://hugo.barrera.io/journal/2022/05/07/how-i-secure-my-setup-with-a-yubikey/" rel="nofollow">https://hugo.barrera.io/journal/2022/05/07/how-i-secure-my-s...</a>
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).<p>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.
Curious, if you delete the stub in ~/.ssh/id_ed25519_sk, can you then recover the key?<p>Or does the on-the-fly key generation use random bytes stored in the stub?
Thanks for sharing the article. I followed it and it was very simple to set up.<p>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.<p>Either case, for this tutorial, I skipped the part running 'ykman'. Basically the only commands were:<p><pre><code> ssh-keygen -t ed25519-sk -O resident
ssh-add -K</code></pre>
For those who like to know more details about Yubikeys, I found this pretty interesting: <a href="https://www.youtube.com/watch?v=INi-xKpYjbE" rel="nofollow">https://www.youtube.com/watch?v=INi-xKpYjbE</a>
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".<p>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.<p>The feature request I'm tracking is here: <a href="https://github.com/FiloSottile/yubikey-agent/issues/95" rel="nofollow">https://github.com/FiloSottile/yubikey-agent/issues/95</a><p>The proposed feature would allow setting a touch policy for the SSH key.
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.<p>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.
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?<p>doesn't that defeat the point of using a yubikey where the private key itself is never read from the device during authentication?
Is there a way to show which SSH keys are loaded on the Yubikey? (It looks like you can store multiple)<p>Also, how can one remove the SSH keys from the Yubikey?<p>I've tried to find articles and SSH on the Yubikey gets very confusing as there seem to be so many techniques!
Some additional information:<p>- <a href="https://www.yubico.com/blog/github-now-supports-ssh-security-keys/" rel="nofollow">https://www.yubico.com/blog/github-now-supports-ssh-security...</a><p>- <a href="https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.html" rel="nofollow">https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht...</a><p>- <a href="https://developers.yubico.com/SSH/" rel="nofollow">https://developers.yubico.com/SSH/</a><p>The second link describes the advantages/disadvantages of non-resident vs. resident keys.
<a href="https://github.com/FiloSottile/yubikey-agent" rel="nofollow">https://github.com/FiloSottile/yubikey-agent</a> has worked really well for me in the past.
> 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.<p>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.
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 (<a href="https://gitlab.com/gitlab-org/gitlab/-/issues/213259" rel="nofollow">https://gitlab.com/gitlab-org/gitlab/-/issues/213259</a>) 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).<p>As a result, lots of systems that are not bleeding edge still don't accept them, for example Gerrit.
> such as the Tongues you received as a kid when you were forced into learning the bible against your will<p>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.
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?