[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.

[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.

[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?

[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.