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.
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.
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.
It’s possible but would not bring you any extra security.
The advantage of non-exportable, HSM-backed keys is that you are guaranteed that the only way to use that key is to have online access to the HSM, and you can recover from HSM access compromise without having to replace the keys.
If you make the key exportable it is no better than if it was stored on your disk to begin with.
As others mention, there is no point to using the Secure Enclave if you have your key stored on disk or in your backup. It’s like putting impressive locks on the front door, while leaving the window open.
Beyond that, you can do that just fine right now by making TWO keys. If you lose the laptop, oh well. Recover with your backup key (which is hopefully kept more securely than you describe - it can be inconvenient to access since it is only needed for recovery).
This also lets you go further in locking things down or providing you notifications, as you can distinguish server side between your usual key and the backup key.
The point of the enclave is to be noncloneable and access limited. Extracting the key for the backup would negate the benefits derived from that.
yes, you can export keys using this method, and they will be simlarly secure as password encrypted keys you generate without the secure enclave with openssh, but with the convenience that you can decrypt the key using TouchID on macOS.
Such a setup is marginally more secure than just typing in the passwords, since it is much harder to intercept the TouchID chain from touch to decrypting the SSH key compared to your keyboard to the terminal.
All that said, here are the priorities of a few security technologies:
TouchID:
#1 environment integrity, that is to say, to protect Apple services monopolies and fees such as eliminating password sharing of services accounts, #2 convenience as an alternative to passwords reducing friction when you buy stuff, #3 security.
1password:
#1 convenience, #2 security
I cannot tell you really what is "#1" in security among packaged ready to buy commercial products, Everyone, practically, makes affordances for convenience ahead of security. I suppose there isn't really a great product for normal people that puts security first. Of course, there are an ad hoc collection of practices that amount to, #1 security. But a product? No. Even Apple Lockdown mode... well, they can still just push an update that makes it pretend it is enabled when it is not, so...
> 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 this case you can maintain an offline SSH CA and trust that on the remote machines, and then sign yourself leaf certificates against a non-exportable HSM-backed key. In case of loss you just make a new key and sign a new certificate.
Of course this just moves the key management problem somewhere else: now you need to protect the CA key, but that might be easier since you would only need access to it in a disaster recovery scenario if you replaced the laptop or otherwise lost access to your HSM-backed key.
Keeping the certificate’s key as non-exportable in the HSM means you do not need to revoke it as it cannot be compromised (not permanently at least), once you’ve regained access to the HSM you can assume the bad guys are out.
Of course the CA key itself is another story, which is why this merely moves the problem elsewhere (however since you only need access to the CA during initial provisioning of a new certificate key, you can better control access to it).
> Keeping the certificate’s key as non-exportable in the HSM means you do not need to revoke it as it cannot be compromised (not permanently at least), once you’ve regained access to the HSM you can assume the bad guys are out.
How so? I can still lose my Yubikey, and even if the attacker can't export the private key corresponding to a CA-signed SSH certificate, they can still use it, no? How would I "regain access" in this scenario?
I was thinking the HSM in this case is your Macbook and its TPM/Secure Enclave, in which case you'd either recover it or assume the attacker is unable to use it due to biometrics/PIN. I guess the Yubikey has a PIN too with a limited number of tries.
Either way, you either recover the HSM and then don't need to rotate the keys, or you don't in which case you either use OpenSSH's key revocation mechanism (which I believe involves distributing some some sort of CRL to every server), use time-limited SSH certificates and wait out the expiry of the compromised key, or scrap the whole CA and start fresh.
Again this depends on your threat model. The somewhat uncommon requirement where you can't manage your own `authorized_keys` on the remote host complicates things a lot; if you could, then you'd use your existing access (sign yourself a new certificate using your SSH CA) to rotate the whole CA... or just keep two keys in there (primary and backup) and skip the whole CA dance, since it's purely a workaround for the hard requirement of only being able to put one key in authorized_keys.
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.
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.
