3 ms·

> An even more robust approach is to use some kind of hardware token that can sign short-lived ssh keys, and teach all your servers how to deal with those. That

> An even more robust approach is to use some kind of hardware token that can sign short-lived ssh keys, and teach all your servers how to deal with those. That’s neat, but it’s hard to deploy (needs custom ssh settings). Ahem, no. I use Yubikeys for a few years now. They are literally braindead to use, and works out of the box in recent Ubuntu. Here is an Ansible role to get started: https://github.com/cristiklein/stateless-workstation-config/blob/master/roles/cklein.security/tasks/main.yaml https://github.com/cristiklein/stateless-workstation-config/... Stop making excuses and start protecting your SSH keys! Disclaimer: I'm not compensated in any way by Yubico, but their product is so darn good that I really want people to start using it.

8fingerlouie 6y ago
I'm currently testing the "longevity" of them. I've had one on my keychain for a couple of years now, and so far it appears to hold up pretty darned well. It sits in my pocket unprotected with all my other keys, and despite its fair share of scratches it still works. The reason for the "testing" is that they appear kinda "flimsy" compared to my Nitrokey, but so far it has stood up to every beating i've given it. +1 for Yubikey.
- darkr 6y ago
  Have used them for the past 6 or so years, and issued as standard to any engineers needing sensitive system access - over 30 or so keys that have been used and thoroughly abused over that time I've only ever seen one broken - somehow an engineer managed to snap off the top half of it that attaches to a keyring. The hardware was still functional though.
  - 8fingerlouie 6y ago
    I have not looked into it, but isn't there some way to "backup" a Yubikey ? There is probably a difference between company usage and personal usage. In a company setting i would expect to have backup yubikeys, but for a personal setup a recovery situation would involve getting your keys "out of it" until a replacement arrives.
    - darkr 6y ago
      When you're generating keys you have two options: 1. Generate keys off card and import them (you can then backup these keys) 2. Generate keys on-card I always chose the 2nd option; not being able to extract the keys from the card is strongly desired security feature.
      - deleted 6y ago
        [deleted]
      - jlgaddis 6y ago
        On the other hand, I chose the first option (several years ago) -- and doing so saved me from having to generate new keys (and rotate them on every host I used) when I got my Yubikeys replaced the second time (due to a bug in the key generation library used on the Yubikey). -- I generated my new GPG key while booted into a "live CD" environment on an air-gapped host. Because I believe in doing things right, I deliberately selected a machine for this task that 1) didn't have Intel AMT/ME, 2) didn't have any wireless network interfaces, 3) had no storage devices installed, and 4) had PS/2 ports for the mouse and keyboard (for "better"entropy)! I set up the new Yubikeys, generated my new GPG master key, and generated a different ("authentication") subkey for each Yubikey. The master (certification) key and signing and encryption subkeys -- but not the authentication subkeys -- were exported and then backed up on a brand new USB flash drive that I'd purchased at a retail store, just taken out of the package, and created a small LUKS-encrypted filesystem on -- using an outrageously long, randomly-generated passphrase, of course. The USB flash drive is kept in a sealed envelope inside a tamper-evident bag that's kept in the safe. The passphrase is kept, well, somewhere else, obviously, as is the passphrase for the GPG master key. Using the keys on the Yubikey doesn't require them; only the PIN -- which is long but not as long as the passphrases -- that exists only in my head -- and that's easy enough; I typically do that a few dozen times a day. Since going through that whole process, there have been two times that I've retrieved the USB flash drive and passphrases. Once was to sign a bunch of GPG keys (from a key-signing party) and the other time was in order to rotate my authentication (SSH) subkeys and "renew" (i.e., extend the expiration date of) the others. Was it a huge pain in the ass? Absolutely! Was it worth it, though? Sure. First and foremost, I don't worry about the security of my keys at all and -- perhaps more importantly -- I don't have to keep an eye out for the next bug that's found in the third-party (Infineon, IIRC) libraries that Yubico chose to use.
michaelt 6y ago
I looked at using this setup once - but the whole setup looked really precarious. Using U2F in the browser, you just buy the cheapest yubikey, plug it in and it works - any OS is fine. But to do the same with SSH you've got to buy a particular yubikey, install five different bits of software, adjust a bunch of config files, restart services, adjust your agent autostart files, upload your 'subkeys' (whatever those are)... and that's just to support one OS. It just seemed like the kind of second-class-citizen setup that barely anyone else is using or testing against, so it'd be constantly breaking down.
- darkr 6y ago
  U2f support is available in recent versions of OpenSSH - though ideally you should to configure a pin code as well, which requires some configuration. Can't speak for how good this support is as I've not used it - but for web it is as you say zero, configuration, and just works, always. For GPG/SSH, there is a bit of an initial setup process to setup the card and generate keys (ideally generate them on-card, so you know they cannot be exist elsewhere) - this can be scripted though, as we have done. As part of our deployment process we generate all needed passphrases and revocation certificates, storing in encrypted storage, as well as uploading the public key to a known URL, which is also referenced in the smartcard configuration. Once the card is setup - all you need on a machine is gnupg/gpg-agent and a ~/.gnupg/gpg-agent.conf file that looks like: no-grab pinentry-program /usr/bin/pinentry-curses default-cache-ttl 2400 default-cache-ttl-ssh 14400 enable-ssh-support Using the card on a new machine is as straightforward as fetching the public key to your local/default keychain (gpg --card-edit, then 'fetch'). Switching between machines is then seamless - we have many engineers switching between macOS + Linux multiple times per day without issue.

8fingerlouie 6y ago

I'm currently testing the "longevity" of them. I've had one on my keychain for a couple of years now, and so far it appears to hold up pretty darned well. It sits in my pocket unprotected with all my other keys, and despite its fair share of scratches it still works. The reason for the "testing" is that they appear kinda "flimsy" compared to my Nitrokey, but so far it has stood up to every beating i've given it. +1 for Yubikey.

darkr 6y ago
Have used them for the past 6 or so years, and issued as standard to any engineers needing sensitive system access - over 30 or so keys that have been used and thoroughly abused over that time I've only ever seen one broken - somehow an engineer managed to snap off the top half of it that attaches to a keyring. The hardware was still functional though.
- 8fingerlouie 6y ago
  I have not looked into it, but isn't there some way to "backup" a Yubikey ? There is probably a difference between company usage and personal usage. In a company setting i would expect to have backup yubikeys, but for a personal setup a recovery situation would involve getting your keys "out of it" until a replacement arrives.
  - darkr 6y ago
    When you're generating keys you have two options: 1. Generate keys off card and import them (you can then backup these keys) 2. Generate keys on-card I always chose the 2nd option; not being able to extract the keys from the card is strongly desired security feature.
    - deleted 6y ago
      [deleted]
    - jlgaddis 6y ago
      On the other hand, I chose the first option (several years ago) -- and doing so saved me from having to generate new keys (and rotate them on every host I used) when I got my Yubikeys replaced the second time (due to a bug in the key generation library used on the Yubikey). -- I generated my new GPG key while booted into a "live CD" environment on an air-gapped host. Because I believe in doing things right, I deliberately selected a machine for this task that 1) didn't have Intel AMT/ME, 2) didn't have any wireless network interfaces, 3) had no storage devices installed, and 4) had PS/2 ports for the mouse and keyboard (for "better"entropy)! I set up the new Yubikeys, generated my new GPG master key, and generated a different ("authentication") subkey for each Yubikey. The master (certification) key and signing and encryption subkeys -- but not the authentication subkeys -- were exported and then backed up on a brand new USB flash drive that I'd purchased at a retail store, just taken out of the package, and created a small LUKS-encrypted filesystem on -- using an outrageously long, randomly-generated passphrase, of course. The USB flash drive is kept in a sealed envelope inside a tamper-evident bag that's kept in the safe. The passphrase is kept, well, somewhere else, obviously, as is the passphrase for the GPG master key. Using the keys on the Yubikey doesn't require them; only the PIN -- which is long but not as long as the passphrases -- that exists only in my head -- and that's easy enough; I typically do that a few dozen times a day. Since going through that whole process, there have been two times that I've retrieved the USB flash drive and passphrases. Once was to sign a bunch of GPG keys (from a key-signing party) and the other time was in order to rotate my authentication (SSH) subkeys and "renew" (i.e., extend the expiration date of) the others. Was it a huge pain in the ass? Absolutely! Was it worth it, though? Sure. First and foremost, I don't worry about the security of my keys at all and -- perhaps more importantly -- I don't have to keep an eye out for the next bug that's found in the third-party (Infineon, IIRC) libraries that Yubico chose to use.

michaelt 6y ago

I looked at using this setup once - but the whole setup looked really precarious. Using U2F in the browser, you just buy the cheapest yubikey, plug it in and it works - any OS is fine. But to do the same with SSH you've got to buy a particular yubikey, install five different bits of software, adjust a bunch of config files, restart services, adjust your agent autostart files, upload your 'subkeys' (whatever those are)... and that's just to support one OS. It just seemed like the kind of second-class-citizen setup that barely anyone else is using or testing against, so it'd be constantly breaking down.

darkr 6y ago
U2f support is available in recent versions of OpenSSH - though ideally you should to configure a pin code as well, which requires some configuration. Can't speak for how good this support is as I've not used it - but for web it is as you say zero, configuration, and just works, always. For GPG/SSH, there is a bit of an initial setup process to setup the card and generate keys (ideally generate them on-card, so you know they cannot be exist elsewhere) - this can be scripted though, as we have done. As part of our deployment process we generate all needed passphrases and revocation certificates, storing in encrypted storage, as well as uploading the public key to a known URL, which is also referenced in the smartcard configuration. Once the card is setup - all you need on a machine is gnupg/gpg-agent and a ~/.gnupg/gpg-agent.conf file that looks like: no-grab pinentry-program /usr/bin/pinentry-curses default-cache-ttl 2400 default-cache-ttl-ssh 14400 enable-ssh-support Using the card on a new machine is as straightforward as fetching the public key to your local/default keychain (gpg --card-edit, then 'fetch'). Switching between machines is then seamless - we have many engineers switching between macOS + Linux multiple times per day without issue.