Like the others have said: You just use multiple. You can just add multiple keys to the authorized_keys file.

This is actually the perfect scenario because an attacker can never get hold of the private key. That means that the key is unique: If it's in your hands, it means an attacker doesn't have it. Most smart cards work this way, they generate the private key inside and it can never leave the hardware, you can only prove you have it by using it to sign or encrypt something.

This is very different from SSH keyfiles on disk which can be stolen in many ways, and as such can be compromised without you ever knowing about it.

It's really cool that we can now use this functionality for SSH too. I currently use Yubikeys in OpenPGP mode for this but I might switch to this once I get a T2-enabled Mac.

"now" is at least 16 years now (with PKCS11 and opensc)

By "you just use multiple", you mean I would have to generate extra private keys, add them to authorized_keys, and store them somewhere other than my mac, right?

Because just by using multiple keys I would still be locked out if all of them were stored in this 'Secretive' app.

If you only have a single SSH key as the only method of authenticating somewhere, you already have a dangerous single point of failure.

Not if you have multiple copies of the private key. But yes, there are advantages to having any given key only exist in one place.

If you are making multiple copies of a private key in different places, why wouldn't you just keep a different private key in each of those places along with its corresponding public key though?

That way, you can remove trust from just one of them if you (e.g.) have your computer stolen.

Well, not exactly, I use multiple physical keys. Yubikeys and OpenPGP smartcards in my case. I use multiple different types too (the OpenPGP cards are quite cheap too).

Is there a convenient way to manage and maintain those keys? Keeping the public key of each device and easily select which ones to place on servers.

Very good question. I've been thinking about a central way to manage keys. There doesn't really seem to be one, and it would be a big point of attack because an attacker might abuse it to add their own key.

Right now what I do is I just log into my servers and copy the list :P I don't have that many anyway.

The openssh people are also advocating certificates now, which means you'll have to set up a PKI, which will take care of revocation and such.

In the case of SSH keys, when you export the key fingerprint you can edit the comment. I like the convention of email address & hostname to disambiguate the entries in a centrally-managed authorized keys list – when you get a new device, update the list and push the new version out.

You aren't. It is the same with Yubikeys, if you use them. You are supposed to generate a certificate per user and device they are using for authentication, which is not a big deal at least for remote login on servers, as you can set an arbitrary number of valid SSH keys.

You are supposed, yes, but it is not necessary with Yubikeys. You can still import private keys into your Yubikey. At work we are using this for group access to some appliances that annoyingly limit the number of SSH authorized keys you can teach them.

Also, there are arguments against generating RSA keys with closed-source software (don't tell me that's all pure hardware in a smartcard). For one, generating keys that are vulnerable to something exotic is very much a viable threat, and yubikeys in particular had an issue where some accidentally created very weak keys.

Sure, you need to make sure the key doesn't leak on it's way, but that's not really the issue.

> and yubikeys in particular had an issue where some accidentally created very weak keys.

So did Debian between 2006 and 2008 https://certlogik.com/debian-weak-key-check/

In OpenSSL. Not in GnuPG. I'm not claiming the latter necessarily has better code, but the former's bad code quality is known.

Yes, but software is easier to fix and the problem is easier and more probable to find.

More importantly: you can check the key generator to not include a Dual_EC_DRBG.

Keep a separate spare set of keys