5 ms·

If you own a MacBook Pro with Touch Id I highly recommend https://github.com/sekey/sekey https://github.com/sekey/sekey. It generates ssh keys in the secure enc

If you own a MacBook Pro with Touch Id I highly recommend https://github.com/sekey/sekey https://github.com/sekey/sekey. It generates ssh keys in the secure enclave (mini HSM chip) and allows you to login to remote machines with Touch Id. The key can never leave the secure enclave.

gleenn 8y ago
That sounds awesome, but isn't that risky? Doesn't that mean you could never make a backup of the key, so if your macbook broke then you'd permanently lose access to whatever the key was protecting?
- saltcured 8y ago
  The solution is not to make backups _of_ a key, but to make backup keys and enroll more than one in authorization lists. This also helps immensely when you want to retire a key, whether due to loss of control or concerns about its strength in the future. Being in the practice of having a set of authorized keys, you can safely remove older ones from authorization lists without locking yourself out.
  - sowbug 8y ago
    It's a change in mindset to treat SSH keys as unique, non-duplicatable physical objects, but it's very comforting to be able to reason precisely about the whereabouts of a given key. It does mean you have to get better at keeping your public key lists up to date, so that revoking a key doesn't need a bunch of manual steps. But that's something Ansible/Chef/Puppet are good at.
    - yjftsjthsd-h 8y ago
      Also worth looking at using a SSH cert-authority, if this is a usecase you're optimizing for.
      - linkregister 8y ago
        Unfortunately, Github among other providers are still in the dark ages and don't recognize ssh certificates. You have to install each key as it's issued.
  - jasonjayr 8y ago
    I should make a patch instead of wishing, but it'd be nice if there was a ~/.ssh/authorized_keys.d/ directory where you could drop lists of keys, instead of trying to merge in changes to the one file ...
    - yjftsjthsd-h 8y ago
      It's kinda ugly, but you could do this by putting `Include config.d/*` at the top of your ~/.ssh/config in order to make ~/.ssh/config.d a thing (LPT: do this anyways; it's a huge quality of life improvement), then dropping in config files to point at keys.
    - swinglock 8y ago
      This is already solved, use ssh-copy-id.
  - ecesena 8y ago
    Totally second this. A secret copied is no longer a secret.
  - m-p-3 8y ago
    Exactly. I use SSH a lot and everytime I have a new device, I'll generate a new key and upload the public key to my servers. I make sure to use good labeling to know which key is on which device (user@hostname) to deprecate them when they get decommissioned.
- drexlspivey 8y ago
  Yes if your MB broke the key is lost but you can always add multiple keys to the remote machine in case that happens.
deleted 8y ago
[deleted]

gleenn 8y ago

That sounds awesome, but isn't that risky? Doesn't that mean you could never make a backup of the key, so if your macbook broke then you'd permanently lose access to whatever the key was protecting?

saltcured 8y ago
The solution is not to make backups _of_ a key, but to make backup keys and enroll more than one in authorization lists. This also helps immensely when you want to retire a key, whether due to loss of control or concerns about its strength in the future. Being in the practice of having a set of authorized keys, you can safely remove older ones from authorization lists without locking yourself out.
- sowbug 8y ago
  It's a change in mindset to treat SSH keys as unique, non-duplicatable physical objects, but it's very comforting to be able to reason precisely about the whereabouts of a given key. It does mean you have to get better at keeping your public key lists up to date, so that revoking a key doesn't need a bunch of manual steps. But that's something Ansible/Chef/Puppet are good at.
  - yjftsjthsd-h 8y ago
    Also worth looking at using a SSH cert-authority, if this is a usecase you're optimizing for.
    - linkregister 8y ago
      Unfortunately, Github among other providers are still in the dark ages and don't recognize ssh certificates. You have to install each key as it's issued.
- jasonjayr 8y ago
  I should make a patch instead of wishing, but it'd be nice if there was a ~/.ssh/authorized_keys.d/ directory where you could drop lists of keys, instead of trying to merge in changes to the one file ...
  - yjftsjthsd-h 8y ago
    It's kinda ugly, but you could do this by putting `Include config.d/*` at the top of your ~/.ssh/config in order to make ~/.ssh/config.d a thing (LPT: do this anyways; it's a huge quality of life improvement), then dropping in config files to point at keys.
  - swinglock 8y ago
    This is already solved, use ssh-copy-id.
- ecesena 8y ago
  Totally second this. A secret copied is no longer a secret.
- m-p-3 8y ago
  Exactly. I use SSH a lot and everytime I have a new device, I'll generate a new key and upload the public key to my servers. I make sure to use good labeling to know which key is on which device (user@hostname) to deprecate them when they get decommissioned.
drexlspivey 8y ago
Yes if your MB broke the key is lost but you can always add multiple keys to the remote machine in case that happens.

deleted 8y ago

[deleted]