5 ms·

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

• jedberg 11mo ago
  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.
  • pi-rat 11mo ago
    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?
    • morshu9001 11mo ago
      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 11mo ago
        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 11mo ago
          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/ssh.nix https://github.com/arianvp/nixos-stuff/blob/master/modules/s...
        • lxgr 11mo ago
          But now you need to worry about revocation or at least key lifetimes.
          • yjftsjthsd-h 11mo ago
            I would argue that doing both of those is still less work than maintaining authorized_keys in many places.
            • morshu9001 11mo ago
              Yes, also idk if the other way works with Secure Enclave
              • morshu9001 11mo ago
                oops replied to wrong comment
        • morshu9001 11mo ago
          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.
      • Nextgrid 11mo ago
        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 11mo ago
          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.
      • QuantumNomad_ 11mo ago
        > 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 11mo ago
        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.
        • ikiris 11mo ago
          ssh has supported signed certs for literal years
        • notpushkin 11mo ago
          SSH CA is what you’re looking for. It’s a thing apparently (but I haven’t tried it yet).
        • 5d41402abc4b 11mo ago
          or FreeIPA?
      • traceroute66 11mo ago
        > I wish there were an easier way, For SSH there is. Its called SSH certificates. ;)
    • vlovich123 11mo ago
      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-systems/raw/ch01.html#on_passwords_and_power_drills https://google.github.io/building-secure-and-reliable-system...
      • sunaookami 11mo ago
        >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!
    • lxgr 11mo ago
      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.
  • eptcyka 11mo ago
    In what scenario would you prefer to backup an SSH key in favor of generating new SSH keys?
    • jedberg 11mo ago
      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.
      • Nextgrid 11mo ago
        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. As usual, it all depends on your threat model.
        • lxgr 11mo ago
          But how do you revoke any compromised certificate if you don't control the remote machines?
          • Nextgrid 11mo ago
            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).
            • lxgr 11mo ago
  • philsnow 11mo ago
    > 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)
  • adastra22 11mo ago
    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.
    • jedberg 11mo ago
      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.
      • Nextgrid 11mo ago
        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.
      • doctorpangloss 11mo ago
        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...
  • fragmede 11mo ago
    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.
  • morshu9001 11mo ago
    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.
• asteroidburger 11mo ago
  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.
  • Nextgrid 11mo ago
    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.
    • asteroidburger 11mo ago
      Not necessarily; "read file" is very different from "execute command." The biometrics part is a substantial lift as well.