8 ms·

And/or use a smartcard to store your SSH keys. With YubiKey 4 being as cheap as they are, there's little excuses :-)

by lima 8y ago

tptacek 8y ago
This is what I meant by "elaborate new plans". I like Y4's as much as the next nerd, but if you're going to put that kind of energy in, spend the energy on setting up an SSH CA.
- knorker 8y ago
  One does not exclude the other. If it did then a hardware token like Yubikey easily beats a CA.
  - deleted 8y ago
    [deleted]
  - lvh 8y ago
    How does it "easily beat" a CA? It's still a long-held credential that you now have to manage across a fleet instead of a single SSH CA. You can get that short-term credential via a long-held key; that long-held key can even live on a Yubikey if you use U2F/WebAuthn. You get all of the security and usability benefits of U2F/WebAuthn as well as the off-boarding/on-boarding/compliance benefits of tying everything to SSO as well as the audit benefits of an SSH CA.
    - knorker 8y ago
      You can work around not having a CA, by distributing keys. I'm exaggerating when I say "just write a script", but it's not hard. You cannot work around not having hardware keys. SSH CAs improve efficiency and convenience. A hardware key that requires touch per login is a game-changer. When you go do lunch you know that your key did nothing, no matter how compromised your workstation is. When your machine is turned off you know that there's no copy of the key somewhere. That key cannot be used. A software cert-based key may be valid for only hours (if you set it up that way), but that means that there are 7 billion possible attackers who could use your key. They could break into your workstation and wait for the screensaver to kick in, and then log in to every single host you have access to, and do their naughty business. For a hardware key someone has to take a plane from China and break into your house to use your key. > It's still a long-held credential Doesn't have to be. But if it is, so what? Given physical locks that are unpickable and keys uncopyable, would you rather instead change locks every day, where the keys are copyable? (even if cost of changing locks scales O(1) with price) > that long-held key can even live on a Yubikey if you use U2F/WebAuthn Like I said, one does not exclude the other. You can't prove that A is better than B by saying A+B is better than B. There's also devices that don't support SSH certificates (e.g. embedded devices), but supporting pubkeys is vastly more common.
      - tialaramex 8y ago
        Technically supporting public keys is mandatory. Of course not only can real world implementations ignore a MUST in the RFC they can also, and more conveniently, just reject all proposed public keys, leaving public key auth as just a stub. One of the servers I've had the misfortune of using responds to even proposed public key auth by failing all subsequent authentication on that connection. So you need to immediately do password auth if you want to get in. Brilliant. I presume the WG specifically wanted to see SSH with public keys deployed widely rather than a world where most places upgrade from telnet to SSH with passwords and think that's the job done.
        knorker 8y ago
        > Technically supporting public keys is mandatory. Yeah, but even if the sshd supports it that doesn't mean that the product has a way to configure it. There may be no non-volatile space for a pubkey. I have encountered it, but yeah it's rare.
  - tialaramex 8y ago
    I agree. Hardware token makes a huge difference here because it ruins attack momentum. The rest of the attack is very technical, very network applicable - copies of key files, guessing passwords - your adversary may be the far side of the world, and they may have done all this in seconds. But suddenly a hardware token means ground assets. Different skill set. Some adversaries may be able to buy all the Cloud Compute and Network Bandwidth they can ask for (especially if it's all with somebody else's credit cards...), but putting even one black bag job together in a foreign country is beyond them. And even for adversaries that are able to do this you can't just spin up ground assets instantly. Yes, in "Rainbows End" Rabbit actually does (if you pay attention) build a ground team to execute the lab infiltration plan despite apparently not having any corporeal existence. But that's science fiction. Here and now that's not how it works.
- lima 8y ago
  I recently rolled out YubiKey 4s to my whole organization and it was a painless experience. There's not a single file-based key left. Provision the keys, replace the old file-based keys via our configuration management tooling, done. Wouldn't a SSH CA just introduce a whole different kind of complexity? - How to protect the SSH CA and its key and make it highly available? I don't want to be locked out of my bastion host after something the CA depended on broke and my certificate has just expired. - How to authenticate users against the CA? Most solutions I've seen use a longer-lived client-side secret, which is just as susceptible to theft than a regular SSH key, or some sort of OAuth or SAML SSO. A malicious Chrome extension can now compromise the SSO process, you still need a U2F token (like a YubiKey 4) to properly secure the SSO account, etc. - How to make it work with our SCM and random things like a storage appliance and various JunOS devices, which support regular SSH keys, but don't know about SSH certificates? I would assume that Latacora is using a SSH CA, and I'm legitimately curious how you approached these challenges.
  - tptacek 8y ago
    We like Y4's just fine. For the very limited set of machines we maintain that we ever need to SSH into, we use Y4 SSH keys. But we don't promote them to clients; we're working on rolling out short-lived SSH credentials with them.
    - Spooky23 8y ago
      Is there a good guide or tool out there for implementing/managing SSH CAs? I don’t really play in this space, but I have some business partners who were struggling with it.
      - lvh 8y ago
        I think the easiest way to get started is to deploy Teleport or BLESS.
  - lvh 8y ago
    You raise a bunch of valid points. Just to answer the one about authing against the CA (I'm in the LV airport for BlackHat and my laptop battery is about to die): yes, still get U2F tokens. You're right that malicious Chrome extensions will mess you up, but that's true for everything else you run too: you need to enforce Chrome extensions via MDM regardless of what your SSH key story looks like. I consider having to SSO in a good thing: it means onboarding/offboarding/audit logging is easier. The context for SSH CA/Teleport is SSHing into a box. When you do actually need an SSH key, Yubikeys are the best answer. (I like using gpg-agent's ssh-agent emulation mode because I find it works better on Macs, but that's irrelevant to the security analysis.)
- dozzie 8y ago
  If only there was a certificate authority management tool that was convenient to use from command line and through an API, so it could be made into a company-wide service. There is this old tinyCA that comes with OpenVPN, but it's awful and can't do much (I don't even remember if it could revoke a certificate). There are a few instances of WWW-only CAs, and there are desktop/GUI applications. But command line? /usr/bin/openssl only, and it's unwieldy. Even worse situation with a CA library. People like to fetishize OpenSSH's CA (for both client keys and server keys), but there still a lot to do before it becomes usable. (Though the same stands for the traditional save-on-first-use method, honestly.) You're basically proposing to deploy software that maybe will be usable in a few years, with a big "maybe", because until now it haven't materialized.
  - amaccuish 8y ago
    Completely agree. Most are horrible enterprisey java stuff. I currently use django-ca.
  - deleted 8y ago
    [deleted]
  - lima 8y ago
    Hashicorp Vault has a great CA.
    - dozzie 8y ago
      Yes, I've seen. Even more unwieldy than OpenSSL's one, and you need whole Hashicorp's thing, too.
- simias 8y ago
  If I use an ssh key to connect to computers owned by multiple organizations and I can't control how those servers are configured can I still use an SSH CA? For instance I use my key to connect to my servers but also computers at work, super short lived sessions when I'm debugging some embedded device through SSH (those tend to be wiped/replaced a lot so I keep having to ssh-copy-id my key to them), github and other "cloud" hosts etc... Does SSH CA make sense in such a configuration? I'm currently using a yubikey to hold my key (in the GnuPG smartcard applet) so I felt pretty confident security-wise but now you're making me doubt.
  - e12e 8y ago
    > If I use an ssh key to connect to computers owned by multiple organizations and I can't control how those servers are configured can I still use an SSH CA? Not really. In general you need the same level of access for setting up the sshd host key, for setting up/enabling sshca: the server must trust the ca pub cert, and there's some configuration needed wrt principals (although AFAIK you can/should embed most of that in the certificate).
- gok 8y ago
  Aren’t Y4s still long lived credentials?
unit91 8y ago
> there's little excuses Yikes that statement has a lot of moral overtones. Is it a good idea to use a Yubi? Arguably yes. Does one need to find "excuses" for not doing so? The vast majority of the time, no.
- lima 8y ago
  No moral overtones intended, the point being that the low cost and the form factor significantly lowers the barrier to entry. I've been using a GPG smart card for a long time, and it required a separate card reader, and both card and reader were easy to break. A YubiKey 4 fits on a keychain, is hard to break (though some of my colleagues succeeded) and you just plug it in.
  - amaccuish 8y ago
    I like my smartcards. Bummed they didn't catch on. How do you feel about losing the PIN and using a password? I like how, if I'm at my desk using a hardware PIN pad, it's much less likely i'll have problems.
    - lima 8y ago
      For SSH, it's fine. The hardware PIN pad does not show which server I'm logging into, so it adds little extra security.
- Latty 8y ago
  I think the intent was more that security keys greatly reduce the friction associated with more secure practices, reducing the reasons to use less secure ones.
jacobvosmaer 8y ago
The user experience of doing this is very bad. Every time I look into doing this I end up with blog posts that describe punching numbers into the GPG CLI, master keys, subkeys, PIN's. I don't want to be a GPG enthusiast, I just want to use my SSH key safely. (No offense to GPG enthusiasts!)
- yayana 8y ago
  I found an X509 oriented device relatively easy for ssh (for gpg it is naturally harder to use these non gpg devices with some kind of bridge daemon). Assuming Linux or OsX where your distribution has an opensc that already supports your device, ssh is only about 3 incantations of magic: https://nilsschneider.net/2013/06/20/epass2003-quickstart.html https://nilsschneider.net/2013/06/20/epass2003-quickstart.ht... But there is no safe way of getting away from having 1 pin.
  - acdha 8y ago
    On current versions of macOS it’s built in so all you need is to generate the key and add one line to your SSH config: PKCS11Provider=/usr/lib/ssh-keychain.dylib https://support.apple.com/en-us/HT208372 https://support.apple.com/en-us/HT208372
- amaccuish 8y ago
  I dislike GPG as well, but I have the OpenPGP smartcard. I've just loaded it with x509 certs. There's OpenSC so I can use it in a browser/VPN/SSH/Apple Mail etc.
- fragmede 8y ago
  That's a side effect of the GPG being the back end technology that the Yubikey-based SSH keys are based on. If you don't want to have to learn gpg (because why should you?) the master/sub keys, PINs, keyservers, and all that can be dumped, just like ssh-keygen is able to create keys without passphrases - not exactly recommended, but still better than the alternative.
  - 8y ago
mfontani 8y ago
I've not been able to find a good tutorial on how to store keys, plural, on a Yubikey 4 or any other smartcards. They're all limited to storing one, maybe two "authentication" GPG keys. Would you have some pointers?
- lvh 8y ago
  That’s right: the number of keys you can store on it is limited. That’s one of the reasons we think you should just use them for identity, not temporary authorization.

And/or use a smartcard to store your SSH keys. With YubiKey 4 being as cheap as they are, there's little excuses :-)

by lima 8y ago

And/or use a smartcard to store your SSH keys. With YubiKey 4 being as cheap as they are, there's little excuses :-)

This is what I meant by "elaborate new plans". I like Y4's as much as the next nerd, but if you're going to put that kind of energy in, spend the energy on setting up an SSH CA.

knorker 8y ago
One does not exclude the other. If it did then a hardware token like Yubikey easily beats a CA.
- deleted 8y ago
  [deleted]
- lvh 8y ago
  How does it "easily beat" a CA? It's still a long-held credential that you now have to manage across a fleet instead of a single SSH CA. You can get that short-term credential via a long-held key; that long-held key can even live on a Yubikey if you use U2F/WebAuthn. You get all of the security and usability benefits of U2F/WebAuthn as well as the off-boarding/on-boarding/compliance benefits of tying everything to SSO as well as the audit benefits of an SSH CA.
  - knorker 8y ago
    You can work around not having a CA, by distributing keys. I'm exaggerating when I say "just write a script", but it's not hard. You cannot work around not having hardware keys. SSH CAs improve efficiency and convenience. A hardware key that requires touch per login is a game-changer. When you go do lunch you know that your key did nothing, no matter how compromised your workstation is. When your machine is turned off you know that there's no copy of the key somewhere. That key cannot be used. A software cert-based key may be valid for only hours (if you set it up that way), but that means that there are 7 billion possible attackers who could use your key. They could break into your workstation and wait for the screensaver to kick in, and then log in to every single host you have access to, and do their naughty business. For a hardware key someone has to take a plane from China and break into your house to use your key. > It's still a long-held credential Doesn't have to be. But if it is, so what? Given physical locks that are unpickable and keys uncopyable, would you rather instead change locks every day, where the keys are copyable? (even if cost of changing locks scales O(1) with price) > that long-held key can even live on a Yubikey if you use U2F/WebAuthn Like I said, one does not exclude the other. You can't prove that A is better than B by saying A+B is better than B. There's also devices that don't support SSH certificates (e.g. embedded devices), but supporting pubkeys is vastly more common.
    - tialaramex 8y ago
      Technically supporting public keys is mandatory. Of course not only can real world implementations ignore a MUST in the RFC they can also, and more conveniently, just reject all proposed public keys, leaving public key auth as just a stub. One of the servers I've had the misfortune of using responds to even proposed public key auth by failing all subsequent authentication on that connection. So you need to immediately do password auth if you want to get in. Brilliant. I presume the WG specifically wanted to see SSH with public keys deployed widely rather than a world where most places upgrade from telnet to SSH with passwords and think that's the job done.
      - knorker 8y ago
        > Technically supporting public keys is mandatory. Yeah, but even if the sshd supports it that doesn't mean that the product has a way to configure it. There may be no non-volatile space for a pubkey. I have encountered it, but yeah it's rare.
- tialaramex 8y ago
  I agree. Hardware token makes a huge difference here because it ruins attack momentum. The rest of the attack is very technical, very network applicable - copies of key files, guessing passwords - your adversary may be the far side of the world, and they may have done all this in seconds. But suddenly a hardware token means ground assets. Different skill set. Some adversaries may be able to buy all the Cloud Compute and Network Bandwidth they can ask for (especially if it's all with somebody else's credit cards...), but putting even one black bag job together in a foreign country is beyond them. And even for adversaries that are able to do this you can't just spin up ground assets instantly. Yes, in "Rainbows End" Rabbit actually does (if you pay attention) build a ground team to execute the lab infiltration plan despite apparently not having any corporeal existence. But that's science fiction. Here and now that's not how it works.
lima 8y ago
I recently rolled out YubiKey 4s to my whole organization and it was a painless experience. There's not a single file-based key left. Provision the keys, replace the old file-based keys via our configuration management tooling, done. Wouldn't a SSH CA just introduce a whole different kind of complexity? - How to protect the SSH CA and its key and make it highly available? I don't want to be locked out of my bastion host after something the CA depended on broke and my certificate has just expired. - How to authenticate users against the CA? Most solutions I've seen use a longer-lived client-side secret, which is just as susceptible to theft than a regular SSH key, or some sort of OAuth or SAML SSO. A malicious Chrome extension can now compromise the SSO process, you still need a U2F token (like a YubiKey 4) to properly secure the SSO account, etc. - How to make it work with our SCM and random things like a storage appliance and various JunOS devices, which support regular SSH keys, but don't know about SSH certificates? I would assume that Latacora is using a SSH CA, and I'm legitimately curious how you approached these challenges.
- tptacek 8y ago
  We like Y4's just fine. For the very limited set of machines we maintain that we ever need to SSH into, we use Y4 SSH keys. But we don't promote them to clients; we're working on rolling out short-lived SSH credentials with them.
  - Spooky23 8y ago
    Is there a good guide or tool out there for implementing/managing SSH CAs? I don’t really play in this space, but I have some business partners who were struggling with it.
    - lvh 8y ago
      I think the easiest way to get started is to deploy Teleport or BLESS.
- lvh 8y ago
  You raise a bunch of valid points. Just to answer the one about authing against the CA (I'm in the LV airport for BlackHat and my laptop battery is about to die): yes, still get U2F tokens. You're right that malicious Chrome extensions will mess you up, but that's true for everything else you run too: you need to enforce Chrome extensions via MDM regardless of what your SSH key story looks like. I consider having to SSO in a good thing: it means onboarding/offboarding/audit logging is easier. The context for SSH CA/Teleport is SSHing into a box. When you do actually need an SSH key, Yubikeys are the best answer. (I like using gpg-agent's ssh-agent emulation mode because I find it works better on Macs, but that's irrelevant to the security analysis.)
dozzie 8y ago
If only there was a certificate authority management tool that was convenient to use from command line and through an API, so it could be made into a company-wide service. There is this old tinyCA that comes with OpenVPN, but it's awful and can't do much (I don't even remember if it could revoke a certificate). There are a few instances of WWW-only CAs, and there are desktop/GUI applications. But command line? /usr/bin/openssl only, and it's unwieldy. Even worse situation with a CA library. People like to fetishize OpenSSH's CA (for both client keys and server keys), but there still a lot to do before it becomes usable. (Though the same stands for the traditional save-on-first-use method, honestly.) You're basically proposing to deploy software that maybe will be usable in a few years, with a big "maybe", because until now it haven't materialized.
- amaccuish 8y ago
  Completely agree. Most are horrible enterprisey java stuff. I currently use django-ca.
- deleted 8y ago
  [deleted]
- lima 8y ago
  Hashicorp Vault has a great CA.
  - dozzie 8y ago
    Yes, I've seen. Even more unwieldy than OpenSSL's one, and you need whole Hashicorp's thing, too.
simias 8y ago
If I use an ssh key to connect to computers owned by multiple organizations and I can't control how those servers are configured can I still use an SSH CA? For instance I use my key to connect to my servers but also computers at work, super short lived sessions when I'm debugging some embedded device through SSH (those tend to be wiped/replaced a lot so I keep having to ssh-copy-id my key to them), github and other "cloud" hosts etc... Does SSH CA make sense in such a configuration? I'm currently using a yubikey to hold my key (in the GnuPG smartcard applet) so I felt pretty confident security-wise but now you're making me doubt.
- e12e 8y ago
  > If I use an ssh key to connect to computers owned by multiple organizations and I can't control how those servers are configured can I still use an SSH CA? Not really. In general you need the same level of access for setting up the sshd host key, for setting up/enabling sshca: the server must trust the ca pub cert, and there's some configuration needed wrt principals (although AFAIK you can/should embed most of that in the certificate).
gok 8y ago
Aren’t Y4s still long lived credentials?

unit91 8y ago

> there's little excuses Yikes that statement has a lot of moral overtones. Is it a good idea to use a Yubi? Arguably yes. Does one need to find "excuses" for not doing so? The vast majority of the time, no.

lima 8y ago
No moral overtones intended, the point being that the low cost and the form factor significantly lowers the barrier to entry. I've been using a GPG smart card for a long time, and it required a separate card reader, and both card and reader were easy to break. A YubiKey 4 fits on a keychain, is hard to break (though some of my colleagues succeeded) and you just plug it in.
- amaccuish 8y ago
  I like my smartcards. Bummed they didn't catch on. How do you feel about losing the PIN and using a password? I like how, if I'm at my desk using a hardware PIN pad, it's much less likely i'll have problems.
  - lima 8y ago
    For SSH, it's fine. The hardware PIN pad does not show which server I'm logging into, so it adds little extra security.
Latty 8y ago
I think the intent was more that security keys greatly reduce the friction associated with more secure practices, reducing the reasons to use less secure ones.

jacobvosmaer 8y ago

The user experience of doing this is very bad. Every time I look into doing this I end up with blog posts that describe punching numbers into the GPG CLI, master keys, subkeys, PIN's. I don't want to be a GPG enthusiast, I just want to use my SSH key safely. (No offense to GPG enthusiasts!)

yayana 8y ago
I found an X509 oriented device relatively easy for ssh (for gpg it is naturally harder to use these non gpg devices with some kind of bridge daemon). Assuming Linux or OsX where your distribution has an opensc that already supports your device, ssh is only about 3 incantations of magic: https://nilsschneider.net/2013/06/20/epass2003-quickstart.html https://nilsschneider.net/2013/06/20/epass2003-quickstart.ht... But there is no safe way of getting away from having 1 pin.
- acdha 8y ago
  On current versions of macOS it’s built in so all you need is to generate the key and add one line to your SSH config: PKCS11Provider=/usr/lib/ssh-keychain.dylib https://support.apple.com/en-us/HT208372 https://support.apple.com/en-us/HT208372
amaccuish 8y ago
I dislike GPG as well, but I have the OpenPGP smartcard. I've just loaded it with x509 certs. There's OpenSC so I can use it in a browser/VPN/SSH/Apple Mail etc.
fragmede 8y ago
That's a side effect of the GPG being the back end technology that the Yubikey-based SSH keys are based on. If you don't want to have to learn gpg (because why should you?) the master/sub keys, PINs, keyservers, and all that can be dumped, just like ssh-keygen is able to create keys without passphrases - not exactly recommended, but still better than the alternative.
- 8y ago

mfontani 8y ago

I've not been able to find a good tutorial on how to store keys, plural, on a Yubikey 4 or any other smartcards. They're all limited to storing one, maybe two "authentication" GPG keys. Would you have some pointers?

lvh 8y ago
That’s right: the number of keys you can store on it is limited. That’s one of the reasons we think you should just use them for identity, not temporary authorization.