46 ms·

I can surely recommend reading into SSH certificates using the ssh-keygen manpage. No any extra tools required. I sign SSH certificates for all my keypairs on

I can surely recommend reading into SSH certificates using the ssh-keygen manpage. No any extra tools required. I sign SSH certificates for all my keypairs on my client devices, principal is set to my unix username, expiry is some weeks or months. The servers have my CA set via TrustedUserCAKeys in sshd_config (see manpages). SSH into root is forbidden per default, i SSH into an account with my principal name and then sudo or doas. My gain in all of this: I have n clients and m servers. Instead of having to maintain all keys for all clients on all servers, i now only need to maintain the certificate on each client individually. If i loose or forget a client, its certificate runs out and becomes invalidated.

jas- 5y ago
Now you have a centralized single point of failure. While the ease of use is inherently obvious with the implementation, if/when it does fail you will have to fall back to public key/password auth anyways.
- blueflow 5y ago
  Which failure mode do you mean? The CA is accessible via offline means. I can walk to it and sign me a new keypair.
  - jon-wood 5y ago
    What happens when the building the CA is in burns down?
    - BenjiWiebe 5y ago
      Scan printed QR codes of your private key that you had backed up off-site.
      - tomrod 5y ago
        That's actually pretty brilliant.
        danuker 5y ago
        Provided you keep said papers away from prying cameras in a verifiable way, that is. For more inspiration, check out the Glacier Protocol. https://glacierprotocol.org/ https://glacierprotocol.org/
        tomrod 5y ago
        Thanks for the heads up! I wish I'd thought about this when playing with bitcoin a few months after launch and amassing an integer value larger than zero. That wallet died with the hard drive.
        aspenmayer 5y ago
        Please tell me you still have the hard drive. There’s a chance for recovery, and I have some experience in this area if you want some tips. Step 0 is always keep your drives for future recovery attempts.
        tomrod 5y ago
        It was dumped many, many years ago while BTC was still a novelty paying for pizza in the thousands BTC per. I went to see if I still had a backup of the wallet with a USD:BTC spike a few years back and it was gone. Life goes on, even when sad things happen :(
        AitchEmArsey 5y ago
        Think of it this way: by starving the supply of that one bitcoin, you have contributed in some small way to the eventual loss of all bitcoins through similar events - speeding up the rate at which the world can move on from this silly fad.
        5y ago
      - politician 5y ago
        Ideally, k-of-n key shards, stored in safety deposit boxes.
    - blueflow 5y ago
      The CA is in a gpg-encryped secrets store (pass) and has a password on itself, so it can be backupped like normal data to an off-site location.
    - hamburglar 5y ago
      Also, this doesn’t apply to most real scenarios (especially not “how I run my personal stuff” type scenarios), but is a fun one to contemplate: what happens when your customer has requirements that specify all keys (including root signing keys) to be rotated at a certain point in the future? Having a process for this is an interesting challenge.
    - remram 5y ago
      The CA is a key, not a network service.
- tptacek 5y ago
  Centralized single points of control are a basic goal of corpsec. They trade availability for security. The alternative model of individual SSH keys is theoretically more highly available, but has many single points of security failure.
  - jas- 5y ago
    Please enlighten me on the ‘many single points of security failure.’
- benlivengood 5y ago
  Sign with two or three CAs, and have sshd accept any of them.
XorNot 5y ago
Expiries are not protection against compromise. Compromises happen in seconds - milliseconds, and once they do they will establish persistence. Expiry systems do not and have never been protection against compromise. They're an auxiliary to revocation systems to let you keep revocation lists manageable. If you don't have revocation lists, or your number of changes is small, you should go ahead and just set your credential expiries to whatever you want - infinity, 100 years, whatever - it won't make the slightest bit of difference. Particularly in the case when they're protecting sudo user credentials, they're no defense at all.
- tomrod 5y ago
  To connect back on my rant -- isn't it amazing the disparity of thoughts around security best practices? How does someone who knows next to nothing become a reliable security professional if even the security professionals disagree on fundamentals?
  - kafkaIncarnate 5y ago
    The fundamentals are that you need to exceed O(2^N) > 80 bits roughly in complexity of your keys. Adding some padding to that is a good idea because some algorithms can be simplified in theory (for instance AES-128 is actually simplified down to like ~118 already through known math). This is for symmetric encryption, and for asymmetric the equivalent is ~1024-bits, so padding it up to 2048-bits is generally the "minimum" for RSA, and some of that math is advancing too so bumping it to 4096-bits isn't a bad idea. If you want to be quantum proof, RSA will be broken so moving to something else like EC is nice. AES would be halved O(sqrt(N)), so AES-128 becomes the equivalent of AES-64, so if you want to be quantum proof there you need to jump up to AES-256 (unless you are using XTS/tweak mode, in which case AES-512). Keep in mind quantum also is not exactly short term practical to accomplish at the moment. You can use whatever technology to accomplish that complexity, be it passwords, SSH keys, or SSH certs. Anything else is just technology architecture noise. Passwords absolutely can clear the O(2^N) > 80 bit threshold. It's just about bytes, and how you store them. Nobody is going to be brute forcing a sufficiently complex password over the network anytime soon unless it isn't actually random but some default password that looks random. Just look at the title of this post: "If you're not using SSH certificates you're doing SSH wrong". It's just completely devoid of environment issues, user issues, datacenter issues, and reeks of elitism. There is no "one true way" despite people's insistence that they are the arbiters of truth. I keep reading here about "you should just use serial over network instead of SSH!" but fail to read about how those serial over network connections are usually less secure than SSH itself. Best practices guides have gone off the rails. They are generally good guidelines, but you have to make sure you are taking into account your own environment and user needs and take them with a grain of salt. Learn for yourself, and read raw facts from real cryptographers and people in the field. Don't take best practices guides as absolute truth, but learn from them. How does one become a security professional? Maybe not with one of those "become a security professional in 30 minutes" packages then start a blog about how everyone isn't conforming to their tiny worldview. No matter what it'll take >10 years with actual experience, just like any profession. One has to start from the bottom and make their way up. Most environments are too complicated for any "one size fits all" solution: https://xkcd.com/927/ https://xkcd.com/927/ EDIT: Further discussion on this here is interesting. The top comments go all in on SSH certificates, then down the line people start questioning why passwords are bad in the same ways. A lot of the "SSL certificate" push theorized here from their perspective seems to come from VPN providers that need it from lesser skilled clients/users (think, people who bought VPNs off YouTube video recommendations): https://arstechnica.com/information-technology/2022/02/after-lying-low-ssh-botnet-mushrooms-and-is-harder-than-ever-to-take-down/?comments=1 https://arstechnica.com/information-technology/2022/02/after...
westurner 5y ago
`ssh-keygen` #Certificates: https://man7.org/linux/man-pages/man1/ssh-keygen.1.html#CERTIFICATES https://man7.org/linux/man-pages/man1/ssh-keygen.1.html#CERT... "DevSec SSH Baseline" ssh_spec.rb, sshd_spec.rb https://github.com/dev-sec/ssh-baseline/blob/master/controls/sshd_spec.rb https://github.com/dev-sec/ssh-baseline/blob/master/controls... "SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes" https://github.com/satoshilabs/slips/blob/master/slip-0039.md#shamirs-secret-sharing https://github.com/satoshilabs/slips/blob/master/slip-0039.m... > Shamir's secret-sharing provides a better mechanism for backing up secrets by distributing custodianship among a number of trusted parties in a manner that can prevent loss even if one or a few of those parties become compromised. > However, the lack of SSS standardization to date presents a risk of being unable to perform secret recovery in the future should the tooling change. Therefore, we propose standardizing SSS so that SLIP-0039 compatible implementations will be interoperable.

jas- 5y ago

Now you have a centralized single point of failure. While the ease of use is inherently obvious with the implementation, if/when it does fail you will have to fall back to public key/password auth anyways.

blueflow 5y ago
Which failure mode do you mean? The CA is accessible via offline means. I can walk to it and sign me a new keypair.
- jon-wood 5y ago
  What happens when the building the CA is in burns down?
  - BenjiWiebe 5y ago
    Scan printed QR codes of your private key that you had backed up off-site.
    - tomrod 5y ago
      That's actually pretty brilliant.
      - danuker 5y ago
        Provided you keep said papers away from prying cameras in a verifiable way, that is. For more inspiration, check out the Glacier Protocol. https://glacierprotocol.org/ https://glacierprotocol.org/
        tomrod 5y ago
        Thanks for the heads up! I wish I'd thought about this when playing with bitcoin a few months after launch and amassing an integer value larger than zero. That wallet died with the hard drive.
        aspenmayer 5y ago
        Please tell me you still have the hard drive. There’s a chance for recovery, and I have some experience in this area if you want some tips. Step 0 is always keep your drives for future recovery attempts.
        tomrod 5y ago
        It was dumped many, many years ago while BTC was still a novelty paying for pizza in the thousands BTC per. I went to see if I still had a backup of the wallet with a USD:BTC spike a few years back and it was gone. Life goes on, even when sad things happen :(
        AitchEmArsey 5y ago
        Think of it this way: by starving the supply of that one bitcoin, you have contributed in some small way to the eventual loss of all bitcoins through similar events - speeding up the rate at which the world can move on from this silly fad.
        5y ago
    - politician 5y ago
      Ideally, k-of-n key shards, stored in safety deposit boxes.
  - blueflow 5y ago
    The CA is in a gpg-encryped secrets store (pass) and has a password on itself, so it can be backupped like normal data to an off-site location.
  - hamburglar 5y ago
    Also, this doesn’t apply to most real scenarios (especially not “how I run my personal stuff” type scenarios), but is a fun one to contemplate: what happens when your customer has requirements that specify all keys (including root signing keys) to be rotated at a certain point in the future? Having a process for this is an interesting challenge.
  - remram 5y ago
    The CA is a key, not a network service.
tptacek 5y ago
Centralized single points of control are a basic goal of corpsec. They trade availability for security. The alternative model of individual SSH keys is theoretically more highly available, but has many single points of security failure.
- jas- 5y ago
  Please enlighten me on the ‘many single points of security failure.’
benlivengood 5y ago
Sign with two or three CAs, and have sshd accept any of them.

XorNot 5y ago

Expiries are not protection against compromise. Compromises happen in seconds - milliseconds, and once they do they will establish persistence. Expiry systems do not and have never been protection against compromise. They're an auxiliary to revocation systems to let you keep revocation lists manageable. If you don't have revocation lists, or your number of changes is small, you should go ahead and just set your credential expiries to whatever you want - infinity, 100 years, whatever - it won't make the slightest bit of difference. Particularly in the case when they're protecting sudo user credentials, they're no defense at all.

tomrod 5y ago
To connect back on my rant -- isn't it amazing the disparity of thoughts around security best practices? How does someone who knows next to nothing become a reliable security professional if even the security professionals disagree on fundamentals?
- kafkaIncarnate 5y ago
  The fundamentals are that you need to exceed O(2^N) > 80 bits roughly in complexity of your keys. Adding some padding to that is a good idea because some algorithms can be simplified in theory (for instance AES-128 is actually simplified down to like ~118 already through known math). This is for symmetric encryption, and for asymmetric the equivalent is ~1024-bits, so padding it up to 2048-bits is generally the "minimum" for RSA, and some of that math is advancing too so bumping it to 4096-bits isn't a bad idea. If you want to be quantum proof, RSA will be broken so moving to something else like EC is nice. AES would be halved O(sqrt(N)), so AES-128 becomes the equivalent of AES-64, so if you want to be quantum proof there you need to jump up to AES-256 (unless you are using XTS/tweak mode, in which case AES-512). Keep in mind quantum also is not exactly short term practical to accomplish at the moment. You can use whatever technology to accomplish that complexity, be it passwords, SSH keys, or SSH certs. Anything else is just technology architecture noise. Passwords absolutely can clear the O(2^N) > 80 bit threshold. It's just about bytes, and how you store them. Nobody is going to be brute forcing a sufficiently complex password over the network anytime soon unless it isn't actually random but some default password that looks random. Just look at the title of this post: "If you're not using SSH certificates you're doing SSH wrong". It's just completely devoid of environment issues, user issues, datacenter issues, and reeks of elitism. There is no "one true way" despite people's insistence that they are the arbiters of truth. I keep reading here about "you should just use serial over network instead of SSH!" but fail to read about how those serial over network connections are usually less secure than SSH itself. Best practices guides have gone off the rails. They are generally good guidelines, but you have to make sure you are taking into account your own environment and user needs and take them with a grain of salt. Learn for yourself, and read raw facts from real cryptographers and people in the field. Don't take best practices guides as absolute truth, but learn from them. How does one become a security professional? Maybe not with one of those "become a security professional in 30 minutes" packages then start a blog about how everyone isn't conforming to their tiny worldview. No matter what it'll take >10 years with actual experience, just like any profession. One has to start from the bottom and make their way up. Most environments are too complicated for any "one size fits all" solution: https://xkcd.com/927/ https://xkcd.com/927/ EDIT: Further discussion on this here is interesting. The top comments go all in on SSH certificates, then down the line people start questioning why passwords are bad in the same ways. A lot of the "SSL certificate" push theorized here from their perspective seems to come from VPN providers that need it from lesser skilled clients/users (think, people who bought VPNs off YouTube video recommendations): https://arstechnica.com/information-technology/2022/02/after-lying-low-ssh-botnet-mushrooms-and-is-harder-than-ever-to-take-down/?comments=1 https://arstechnica.com/information-technology/2022/02/after...

westurner 5y ago

`ssh-keygen` #Certificates: https://man7.org/linux/man-pages/man1/ssh-keygen.1.html#CERTIFICATES https://man7.org/linux/man-pages/man1/ssh-keygen.1.html#CERT... "DevSec SSH Baseline" ssh_spec.rb, sshd_spec.rb https://github.com/dev-sec/ssh-baseline/blob/master/controls/sshd_spec.rb https://github.com/dev-sec/ssh-baseline/blob/master/controls... "SLIP-0039: Shamir's Secret-Sharing for Mnemonic Codes" https://github.com/satoshilabs/slips/blob/master/slip-0039.md#shamirs-secret-sharing https://github.com/satoshilabs/slips/blob/master/slip-0039.m... > Shamir's secret-sharing provides a better mechanism for backing up secrets by distributing custodianship among a number of trusted parties in a manner that can prevent loss even if one or a few of those parties become compromised. > However, the lack of SSS standardization to date presents a risk of being unable to perform secret recovery in the future should the tooling change. Therefore, we propose standardizing SSS so that SLIP-0039 compatible implementations will be interoperable.