5 ms·

One difference is that MitM attacks can capture your password, thereby giving persistent access to at least that system (more, if you reuse passwords). With pu

One difference is that MitM attacks can capture your password, thereby giving persistent access to at least that system (more, if you reuse passwords). With public keys, this is not possible. The worst case of credential theft from MitM would be hijacking a forwarded SSH agent, which would require a deliberate (and highly discouraged) client configuration. I feel like syncing a password-protected private key for break-glass use would be better than syncing a password database (given the same master password, key-stretching, and syncing strategy...or even just encoding your private key in a "secure note" field instead).

kazinator 2y ago
SSH is always using public keys even when you use password authentication. Your SSH client knows the host the key. If you're not connecting to the right host, you are informed.
- KAMSPioneer 2y ago
  I know that, but "public keys" is long enough on mobile without typing "public user-authentication keys." Anyway, I think it is reasonable to assume that if you're using the "escape hatch" as mentioned by /u/nine_k, you may well not have your .ssh/known_hosts file on your client. In which case public user-authentication keys minimizes your blast radius of a MitM host. Also, a compromised (but legitimate) host could still grab your password and try lateral movement (mitigated if you don't reuse your break-glass password, but you get it for free with public keys).
  - kazinator 2y ago
    I could host my known_hosts file at a https URL.
    - KAMSPioneer 2y ago
      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

SSH is always using public keys even when you use password authentication. Your SSH client knows the host the key. If you're not connecting to the right host, you are informed.

KAMSPioneer 2y ago
I know that, but "public keys" is long enough on mobile without typing "public user-authentication keys." Anyway, I think it is reasonable to assume that if you're using the "escape hatch" as mentioned by /u/nine_k, you may well not have your .ssh/known_hosts file on your client. In which case public user-authentication keys minimizes your blast radius of a MitM host. Also, a compromised (but legitimate) host could still grab your password and try lateral movement (mitigated if you don't reuse your break-glass password, but you get it for free with public keys).
- kazinator 2y ago
  I could host my known_hosts file at a https URL.
  - KAMSPioneer 2y ago
    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.