[pi-rat]

You can use more than one key you know.

Keep the private key you actively use in the secure enclave. The system you actively use is most at risk.

Keep a secondary offline private key as backup. You can generate and store it in a secure location, and never move it around. Airgapped even if you want. You could even use a yubikey or other hardware for the secondary key giving you two hard to export keys.

Distribute pub keys for both of them.

Best of both worlds?

[vlovich123]

It’s important to remember that over time systems develop complexities that can be hard to recover from scratch because by definition air gapped data aren’t ones you are regularly exercising. Here’s an example of this in action from Google’s history

https://google.github.io/building-secure-and-reliable-system...

[sunaookami]

>It took an additional hour for the team to realize that the green light on the smart card reader did not, in fact, indicate that the card had been inserted correctly. When the engineers flipped the card over, the service restarted and the outage ended.

This is some good read!

[morshu9001]

Yeah but if you get a new device, you have to go add its pubkey to every server you ever use. I wish there were an easier way, otherwise it's understandable that people copy privkeys.

[yjftsjthsd-h]

There is an easier way: Create a SSH CA, add that to your authorized_keys everywhere, use it to sign the individual public keys.

[arianvanp]

Yep that's what I do! I have two ssh-ca's stored on two Yubikeys. And both are trusted by my servers.

If I lose one I can still sign new certs with the other.

https://github.com/arianvp/nixos-stuff/blob/master/modules/s...

[morshu9001]

That's good but more complicated, and not everything supports it. Like on GitHub, SSH CA requires subscribing to their enterprise service.

Also idk if you can store the root or the resulting signed key in the enclave the way this article says.

[lxgr]

But now you need to worry about revocation or at least key lifetimes.

[yjftsjthsd-h]

I would argue that doing both of those is still less work than maintaining authorized_keys in many places.

[morshu9001]

Yes, also idk if the other way works with Secure Enclave

[morshu9001]

oops replied to wrong comment

[QuantumNomad_]

> if you get a new device, you have to go add its pubkey to every server you ever use

It’s not too bad, if the number of servers is not too high.

I have different client pub keys on my phone, multiple laptops and desktop computers and manage my authorized keys to be able to ssh into my servers from the devices, as well as from one laptop to another or from my phone to one of the laptops, etc.

Because I already have several client devices I don’t really need any backup ssh keys. The fact that each device has a different key means that if one laptop breaks or my phone is stolen, I can still ssh into everything from one of the remaining devices and remove the pub key of the broken or stolen device from authorized keys and generate new keys on new devices and then using one of the existing devices to add the pub key of the new device to the authorized keys of the servers and other devices.

For me it’s manageable to do it manually. But if you have very many servers you’d probably want to use a configuration management tool like Chef, Ansible, Puppet or Saltstack. Presumably if you have a very high number of servers you’d already be using a configuration management tool like one of those for other configs and setup anyways.

[miki123211]

There is an easier way, it's called TLS certificates, it's just that SSH decided not to use it for some reason.

Other systems of this nature have figured out long ago that you should be able to have one personal certificate (stored securely in an airgapped environment), from which you'd generate leaf certificates for your devices every year.

[notpushkin]

SSH CA is what you’re looking for. It’s a thing apparently (but I haven’t tried it yet).

[ikiris]

ssh has supported signed certs for literal years

[5d41402abc4b]

or FreeIPA?

[Nextgrid]

If you’re operating at the scale this is too cumbersome to do manually surely you already have a configuration management system in place to automate this no?

[morshu9001]

I have keys tied to several random things, including home servers, GitHub, and AWS. Wouldn't call this scale exactly, but when I got a new laptop, it was way easier to just copy .ssh onto it rather than hunting everything down.

[traceroute66]

> I wish there were an easier way,

For SSH there is.

Its called SSH certificates. ;)

[lxgr]

That can work really well for systems where you don't need to share your key material very often, or where sharing is optimized for n-key scenarios.

SSH isn't always that. For example, ssh-copy-id by default does not copy over multiple identities.

For that reason, I'd personally prefer to import my (otherwise airgapped) key into my secure hardware exactly once and mark it as non-exportable in the SSH scenario.