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.
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
>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.
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.
> 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.
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.
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?
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.
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.
I remember a few years ago when our niece came to visit. One evening, we started watching a movie on Netflix together.
We only made it halfway before bedtime, but since she was coming back in two weeks, we decided to save the rest for her next visit.
Two weeks later, she returned, bouncing with excitement to finally see how the story ended. We opened Netflix, ready to hit play - and lo and behold… the movie had vanished from the catalog.
> I don't own an iPhone so I don't know for sure if old messages clog iPhones too but the article hints that this is the case.
> Maybe Apple is happy to sell new phones with more storage to people that run out of space. Maybe iMessage is a tiny storage eater, maybe not. Photos, videos, vocal messages are on the phone forever too?
iOS has a built in tool that help you identify and clean up space hogs. It’s first recommendation is usually to remove large messages attachments. It will show you a list of all attachments (descending size), you select the ones you want to remove and hit delete. It also offers to automatically delete messages after some time. It’s a global option though, not per chat, not usable if you only want some to be ephemeral.
Timekeeping starts to become really hard, often requiring specialized hardware and protocols.