Comment by cedws
5 months ago
You're not really supposed to 'export' keys. Any time you move a key you risk exposing it. The idea of PKI is that only public keys move, the private key stays in one place, ideally never seen.
5 months ago
You're not really supposed to 'export' keys. Any time you move a key you risk exposing it. The idea of PKI is that only public keys move, the private key stays in one place, ideally never seen.
I've been in the security space for 25 years, and understand the theory of PKI. But I've also been in the ops space for 30 years, and understand that if you don't balance security theory with operational practice, critical business functions can fail.
Ideally yes, the private key is never seen. In reality, it needs to be backed up in a secure place so it can be restored in the event of a failure.
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?
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...
1 reply →
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.
15 replies →
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 think you are mixing up concerns. You need a backup key. That doesn't mean you need to backup your key.
Anything (everything?) using SSH authentication supports multiple authentication keys. Have a yubikey in a locked deposit box or something.
Today I make a private/public keypair, and the private key is on my laptop in my encrypted home folder. It also gets backed up to my encrypted offsite backup. That way if my laptop breaks or is stolen, I can restore from backup and be up and running as before.
I was simply asking if that is still possible with this method, nothing more.
And not every service that uses ssh auth allows multiple keys.
5 replies →
No but that’s the point. If there’s a copy of the private key out there, then it can be copied. The whole point is that the jedberg-laptop-1 key only ever exists as jedberg-laptop-1. When that laptop gets lost/stolen/destroyed/aged out, there's 100% certainty that it can't be recreated. The other side of that equation is that you need a tree of keys and a whole IT department to manage them so you don't get locked out of your servers. This particular bit of software is about ssh keys and exists within a larger conversation about PKI which you know more about than I, but operationally, you have this, and then you have a root login private key file locked with Shamir secret sharing (ssss on debian) that you distribute to a very select few number of key bearers. And then don't all get on the same plane together, ever.
This was a thing with Google Authenticator. People kept asking how to back up or transfer keys, official answer was you can't and WAI. Eventually they conceded and added a backup option, but it was still confusing. I think this ruined the entire reputation of TOTP.
> if you don't balance security theory with operational practice, critical business functions can fail
i.e. people will circumvent the secure-but-onerous path. (I don't think they can be faulted for trying to get their work done either, I'm agreeing with you)
In what scenario would you prefer to backup an SSH key in favor of generating new SSH keys?
When I have my pub key in the authorized_keys files of many machines, especially machines where I don't control the authorized_keys file.
5 replies →
It's much safer to export a key one time and import it into a new machine, or store it in a secure backup, than to keep it just hanging out on disk for eternity, and potentially get scooped up by whatever malware happens to run on your machine.
Any malware capable of exfiltrating a file from your home folder is also capable of calling the export command and tricking you into providing biometrics.
Not necessarily; "read file" is very different from "execute command." The biometrics part is a substantial lift as well.