3 ms·

And yet syncing an encrypted private key is still easier and more secure than syncing (via the same mechanism e.g. Keepass) a 30-character random password.

kazinator 2y ago
You don't need a 30 character random password for SSH to your machine; that's a strawman. The attackers are not cracking a password hash with GPUs; they are just connecting and guessing. People who use passwords with SSH of course use passwords they can remember and type. If the attackers are trying to brute-force your password by attacking the hash, that means the machine was already compromised. The password then has no value, unless you're re-using it for other machines. The user who thinks they need a 30 character random password for SSH (if they were to use one) will of course opt for keys instead.
- KAMSPioneer 2y ago
  A strawman??? It's _word for word_ the suggestion I was responding to in my original comment, how is that a strawman???
  - kazinator 2y ago
    I see user nine_k introduced that. It's still a strawman; nobody needs 30 random characters for a SSH password (except in some circumstances in which a key would obviously be better). Let's assume I have an uncommon user name (not root or www-data, ...) and not anything from my domain name or e-mail address or whatever, and a nine character password made of lower case characters and digits, reasonably easy to remember.
    - KAMSPioneer 2y ago
      Well great, so I'm addressing nine_k and his question/scenario. As I have been this entire time. And it sounds like you're _agreeing_ that a 30-character random password makes no sense, and a key is easier and better. No? Regarding _your_ scenario, cool bro, do whatever you want. However, if you reuse that password for any other servers, you're open to lateral movement attacks, which keys mitigate. Actually I guess that's my main argument: you can mitigate the downsides of passwords, but keys are super simple, well-supported, and require no such fussiness. Just generate it, set a password, authorize it, forget it. Threats mitigated. If you want to futz about with workarounds, be my guest. I have no such desire.
      - kazinator 2y ago
        Anything is better than a 30 character password, including quitting computing and just doing vegetable farming on a tiny island, completely off every grid. BTW, that remark I made about known_hosts applies to keys. You could put your SSH client keys (I mean private ones) on some HTTPS URL, so that you could fetch them to a brand new machine (e.g. burner phone purchased abroad). And that's back to passwords: anyone else knowing that URL could fetch those keys, and their security depends on their password phrase. So we are back to relying on the strength of a password phrase as well as faith in attackers not knowing anything about such an URL. Oh right; the URL could be .htpasswd protected too, let's not forget. :)
        KAMSPioneer 2y ago
        Re: hosting your key, I think that's quite reasonable, again, assuming your access control + encryption is good. It's a solid break-glass solution. I would add monitoring that alerts if it is ever used, though. Then you can remediate quickly on the off-chance it is compromised. In day-to-day use I would stick with a different key that only lives on my machine.
        kazinator 2y ago
        > assuming your access control + encryption is good Accessing a password-protected page over https is pretty much exactly the same access control + encryption as using a password with SSH.
        KAMSPioneer 2y ago
        That's access control and transport encryption. By encryption I meant the encryption of the private key itself. I would not upload a plaintext private key, especially for privileged account access, even to a server I control.
  - nine_k 2y ago
    A strawman indeed. 30 characters is deliberate overkill. So, thank you for confirming my understanding: keys are just as / more convenient from the ops standpoint than passwords. The weakness is only in short, guessable passwords.
    - kazinator 2y ago
      Short, guessable passwords are another strawman. There are short passwords which are unguessable. Those passwords are crackable from their hash, which is different from guessable.

kazinator 2y ago

You don't need a 30 character random password for SSH to your machine; that's a strawman. The attackers are not cracking a password hash with GPUs; they are just connecting and guessing. People who use passwords with SSH of course use passwords they can remember and type. If the attackers are trying to brute-force your password by attacking the hash, that means the machine was already compromised. The password then has no value, unless you're re-using it for other machines. The user who thinks they need a 30 character random password for SSH (if they were to use one) will of course opt for keys instead.

KAMSPioneer 2y ago
A strawman??? It's _word for word_ the suggestion I was responding to in my original comment, how is that a strawman???
- kazinator 2y ago
  I see user nine_k introduced that. It's still a strawman; nobody needs 30 random characters for a SSH password (except in some circumstances in which a key would obviously be better). Let's assume I have an uncommon user name (not root or www-data, ...) and not anything from my domain name or e-mail address or whatever, and a nine character password made of lower case characters and digits, reasonably easy to remember.
  - KAMSPioneer 2y ago
    Well great, so I'm addressing nine_k and his question/scenario. As I have been this entire time. And it sounds like you're _agreeing_ that a 30-character random password makes no sense, and a key is easier and better. No? Regarding _your_ scenario, cool bro, do whatever you want. However, if you reuse that password for any other servers, you're open to lateral movement attacks, which keys mitigate. Actually I guess that's my main argument: you can mitigate the downsides of passwords, but keys are super simple, well-supported, and require no such fussiness. Just generate it, set a password, authorize it, forget it. Threats mitigated. If you want to futz about with workarounds, be my guest. I have no such desire.
    - kazinator 2y ago
      Anything is better than a 30 character password, including quitting computing and just doing vegetable farming on a tiny island, completely off every grid. BTW, that remark I made about known_hosts applies to keys. You could put your SSH client keys (I mean private ones) on some HTTPS URL, so that you could fetch them to a brand new machine (e.g. burner phone purchased abroad). And that's back to passwords: anyone else knowing that URL could fetch those keys, and their security depends on their password phrase. So we are back to relying on the strength of a password phrase as well as faith in attackers not knowing anything about such an URL. Oh right; the URL could be .htpasswd protected too, let's not forget. :)
      - KAMSPioneer 2y ago
        Re: hosting your key, I think that's quite reasonable, again, assuming your access control + encryption is good. It's a solid break-glass solution. I would add monitoring that alerts if it is ever used, though. Then you can remediate quickly on the off-chance it is compromised. In day-to-day use I would stick with a different key that only lives on my machine.
        kazinator 2y ago
        > assuming your access control + encryption is good Accessing a password-protected page over https is pretty much exactly the same access control + encryption as using a password with SSH.
        KAMSPioneer 2y ago
        That's access control and transport encryption. By encryption I meant the encryption of the private key itself. I would not upload a plaintext private key, especially for privileged account access, even to a server I control.
- nine_k 2y ago
  A strawman indeed. 30 characters is deliberate overkill. So, thank you for confirming my understanding: keys are just as / more convenient from the ops standpoint than passwords. The weakness is only in short, guessable passwords.
  - kazinator 2y ago
    Short, guessable passwords are another strawman. There are short passwords which are unguessable. Those passwords are crackable from their hash, which is different from guessable.