I deleted all my SSH keys (blog.infected.systems)

> This post documents how I’m using various secure enclaves (YubiKey, TPM, Apple Secure Enclave) to hold/encrypt SSH key material and achieve the goal of not having any unprotected key material living on-disk.

Could you help me out and state the goal of your practices as simply as this? I can guess, but I'm really not sure, especially when you get into nftables checks for window sizes.

Did you create your own process for monitoring/alerting on the checksum?

I have a handful of security keys, so I have a helper script to drop them into new hosts and another helper script on my systems to import keys straight to ssh-agent once detected.

Has worked very well and I don't think I'll ever go back to a "password manager as SSH agent" again, but it's probably the best alternative backup. I still have Bitwarden holding some backup keypairs for this reason, but haven't needed to use them in months.

Edit: well, maybe not exact. With -sk keys you’d have to type in a passphrase instead of a pin. But that passphrase could be a pin.

If you have just one Yubikey and you lose it, then you lose your SSH access.

But that's true as well if you have just one SSH key on your computer and you lose your computer, right?

I have offline key on two different devices, haven't lost one yet over the last decade!

> All YubiKeys have a storage temperature range between -20°C to 85°C (-4°F to 185°F)

https://docs.yubico.com/hardware/yubikey/datasheet/_static/Y...

The downside with resident keys is that someone stealing the yubikey can see what resident keys are on it, and then possibly use those keys (if they aren’t protected). Newer firmware comes with ways to protect against this, but you’d have to enable it.

[1] has more details

1: https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht...

Anyway, resident key means that you can extract the public key from the yubikey. Say someone steals your Yubikey Fido2 PIN and your Yubikey, they have everything.

Non-resident key means that the attacker needs to get that "useless" file you describe, too. And if you lose it, then you can't use the key anymore.

Another difference is that a resident key takes space on the Yubikey, so you can't have infinitely many. Whereas you can have infinitely many "useless" files.

In the first one the handle file that's created, can be recovered from the yk key itself, that's what resident is.

Having the only practical difference between the two is that, with the first one, you (or someone else) only needs the yk to use the credential. But in the latter case, one needs the yk and the handle file.

What happens when you replace the ThinkPad?

This means someone with access to your filesystem can’t just copy the key off.

Of course a passphrase is another protective layer. But passphrases can be keylogged, or the decrypted key (or passphrase, depending) in the memory of an ssh agent can be can potentially be read out by an attacker.

With separate hardware, the assumption is that the hardware is much much harder to attack, so the keys stay on there and only on there.

If someone steals your Yubikey without compromising your computer, they cannot use it without the passphrase.

If someone compromises your computer to copy your passphrase, AND steals your Yubikey, then they can use it. But you will know that you are not in possession of your Yubikey anymore, and you can do something about it.

Anecdotally I have keys from 2013 that are still working fine when I test them, although they've been superseded by newer models.

To my knowledge no one has done the Consumer Reports / Mythbusters style of testing, buying many Yubikeys over time (to get different hardware batches) and subjecting them to various tests...

There is only one answer to your question: It is irrelevant.

Yubikeys are not that expensive, and anybody who depends on Yubikeys should have minimum two of them.

This isn't a Yubikey thing. Its a basic IT equipment redundancy 101 ... if its important, minimum N+1 it.

The same reason you don't put all your eggs on a single disk.

If you're using tmux on the VPS this can get a little tricky, because by default your tmux panes will inherit your initial SSH client's SSH_AUTH_SOCK; when you re-attach tmux in a different SSH session you'll no longer be able to authenticate with the local YubiKey. But I wrote a shell script that hooks into tmux to keep SSH_AUTH_SOCK working correctly with this kind of setup: https://github.com/mshroyer/socklink

Something about stealing an iPhone jailbreak years ago?

fido, gpg, piv all work perfectly

They started selling the Nitrokey 3 long (like years) before the software had the main features they claimed they had, so I understand why they would want to be able to push updates. But again in terms of security, the first thing I want from a security key is that a compromised computer cannot reflash it...

Whether you want or don't want that property is a different story.

I thought private keys were meant to be secret (not copied) and the public keys meant to be installed onto the target host.

so if you have a desktop, laptop etc, you would generate the secret once per endpoint and then copy the public keys onto targets as needed. AT scale this could be done by ldap / cloud mgmt.

I add YubiKeys as backup everywhere I can. Like I have one YubiKey that always stays at home in case I lose my laptop and phone so I can get access back to some stuff sooner than later.