6 ms·

I think the explanation for most bad defaults in ssh is "redhat" which is kinda insane but I very much stay out of that sandbox. The default can't be changed un

I think the explanation for most bad defaults in ssh is "redhat" which is kinda insane but I very much stay out of that sandbox. The default can't be changed until existing systems can read the new keys. So like 2028 or something.

irrational 8y ago
Why can't it be fixed and then just break for Redhat (until Redhat rolls out fixes/patches)?
detaro 8y ago
For the key storage format, not the key type, wouldn't that only be a problem where you copied a key to a redhat system? Requiring conversion there doesn't sound too bad?
- cbhl 8y ago
  You're basically asking a "you broke my workflow" kind of question. https://xkcd.com/1172/ https://xkcd.com/1172/ In high school, I definitely kept password-protected private keys on a USB key that got plugged into whatever machine happened to be available. (Now I am affluent enough to carry around a real Security Key and a trusted laptop.) If you were the maintainer, would you really want to change the defaults and deal with the backlash of complaints from users who do copy keys around?
  - jessaustin 8y ago
    Even the OpenSSH people will tell you not to copy private keys around. Non-ephemeral private keys should be generated where they will be used. You can copy the public key...
    - Dylan16807 8y ago
      Okay I generated a key on a computer that I will only be using for the next 3 hours, and may never see again. How do I install it? Is that method actually more secure than carrying around an encrypted key?
      - maxerickson 8y ago
        It doesn't take that long to arrive at the conclusion that you should not expose any secret to untrusted hardware. So creating a one time use key for that computer is probably a good idea, you can revoke it once you are done using it and then it won't cause you any problems in the future.
      - angry_octet 8y ago
        Yep, there is no point in generating a new key if you can't get the other end to trust it. You could generate a new trusted key every time you log on (and encrypt with password), and invalidate the old key, making sure to copy it to your USB. That would roll the keys, and cause you to be locked out with that key if anyone used it. But a bit involved. Single use login codes on paper probably the easiest way around the problem. https://www.digitalocean.com/community/tutorials/install-and-use-otpw https://www.digitalocean.com/community/tutorials/install-and... Also, you can configure the google-authenticator TOTP module to request key and token IIRC. GA also has OTPW backup codes.
nwmcsween 8y ago
obsd is highly break-things-for-security and pick up the pieces later so saying Linux is the reason kind of baffles me.

irrational 8y ago

Why can't it be fixed and then just break for Redhat (until Redhat rolls out fixes/patches)?

detaro 8y ago

For the key storage format, not the key type, wouldn't that only be a problem where you copied a key to a redhat system? Requiring conversion there doesn't sound too bad?

cbhl 8y ago
You're basically asking a "you broke my workflow" kind of question. https://xkcd.com/1172/ https://xkcd.com/1172/ In high school, I definitely kept password-protected private keys on a USB key that got plugged into whatever machine happened to be available. (Now I am affluent enough to carry around a real Security Key and a trusted laptop.) If you were the maintainer, would you really want to change the defaults and deal with the backlash of complaints from users who do copy keys around?
- jessaustin 8y ago
  Even the OpenSSH people will tell you not to copy private keys around. Non-ephemeral private keys should be generated where they will be used. You can copy the public key...
  - Dylan16807 8y ago
    Okay I generated a key on a computer that I will only be using for the next 3 hours, and may never see again. How do I install it? Is that method actually more secure than carrying around an encrypted key?
    - maxerickson 8y ago
      It doesn't take that long to arrive at the conclusion that you should not expose any secret to untrusted hardware. So creating a one time use key for that computer is probably a good idea, you can revoke it once you are done using it and then it won't cause you any problems in the future.
    - angry_octet 8y ago
      Yep, there is no point in generating a new key if you can't get the other end to trust it. You could generate a new trusted key every time you log on (and encrypt with password), and invalidate the old key, making sure to copy it to your USB. That would roll the keys, and cause you to be locked out with that key if anyone used it. But a bit involved. Single use login codes on paper probably the easiest way around the problem. https://www.digitalocean.com/community/tutorials/install-and-use-otpw https://www.digitalocean.com/community/tutorials/install-and... Also, you can configure the google-authenticator TOTP module to request key and token IIRC. GA also has OTPW backup codes.

nwmcsween 8y ago

obsd is highly break-things-for-security and pick up the pieces later so saying Linux is the reason kind of baffles me.