2 ms·

I don’t mean using SSH without keys (?), I mean why use SSH instead of HTTPS? I see about two possible cases: 1) One uses Git CLI and wants to get rid of ince

I don’t mean using SSH without keys (?), I mean why use SSH instead of HTTPS? I see about two possible cases: 1) One uses Git CLI and wants to get rid of incessant password prompts this way. 2) One has a setup in which multiple servers access a private Git repo, and wants each server to use different credentials. This doesn’t seem worth the trouble in simpler scenarios when the user accesses Git from one or two personal machines and is entirely fine just changing their password/revoking PAT if it is compromised.

tialaramex 6y ago
Because SSH actually delivers appropriate user security? In HTTPS the model is, you and the server both know a secret, your "password" and then you... just tell them your secret each time to authenticate. That's a pretty good model if you're a ten year old playing forts out in the woods, but it's far below what we ought to be achieving for a service like this. It's true that this plaintext password authentication is normal for the web, which is basically Tim (Berners-Lee)'s fault but that doesn't magically make it a good idea, and it makes sense that GitHub doesn't want "Yes it's crap but it's no worse than the web" to be all they're delivering.
- strogonoff 6y ago
  Care to share any specific advantages, aside from the general notion of “appropriate security”?
  - tialaramex 6y ago
    SSH authentication is a public key authentication so: The relying party (GitHub in this case) learn nothing secret. Your authentication credentials literally can't be stolen from GitHub because they don't have them, so you don't need to care about how well they try to protect them. A MITM learns nothing secret. If things go wrong and you somehow allow a MITM attack to occur, the MITM doesn't get durable credentials from you, once you are talking to GitHub not the MITM they're locked out, even though they watched you authenticate successfully, perhaps many times, they do not learn how to forge working credentials.
    - strogonoff 6y ago
      Thanks for elaborating. > If things go wrong and you somehow allow a MITM attack to occur I get the point, though perhaps the phrasing could do with a little less victim-shaming. How many of the times you were MITMed did you allow that to happen? Now count cases about which you still don’t know. > Your authentication credentials literally can't be stolen from GitHub because they don't have them, so you don't need to care about how well they try to protect them. To me, secret management on the side of an unsophisticated user is arguably of more worry than someone breaking into GitHub and stealing PATs. Consider if a user is casually contributing to documentation on GitHub using some Git client which forces them to supply an SSH key for authentication. Now there is more than one way things could go wrong, for example: 1) They use a key without a passphrase, and it is stored somewhere on their filesystem (perhaps under ~/.ssh, where ssh-keygen wants to place it by default) where any app with disk access can read it. Voila, a third party gets full access to their GitHub repositories. 2) They use a weak passphrase, reuse an old password for passphrase, or store the passphrase in plain text. Similar liability. Meanwhile, PAT is: long, auto-generated by GitHub (so one can’t reuse a password), shown only once, doesn’t make sense for the user to save, and the client can make sure to store it using a sound mechanism (e.g., Keychain on macOS). That said, a well-behaved user-friendly Git client could neutralize some of the downsides by taking care of generating a completely new, passphrase-protected SSH keypair under the hood, storing the passphrase and the private part reliably, and asking the user to add the public part to their GitHub account, each time it is set up on a new machine. I wonder how many clients go to such lengths.
      - tialaramex 6y ago
        > Meanwhile, PAT is: long, auto-generated by GitHub (so one can’t reuse a password), shown only once, doesn’t make sense for the user to save, and the client can make sure to store it using a sound mechanism (e.g., Keychain on macOS). Right, so, with a lot of extra hoop jumping GitHub have been able to special case HTTPS authentication for their site so that if you use these tokens it's only somewhat worse than what you get out of the box with SSH.

tialaramex 6y ago

Because SSH actually delivers appropriate user security? In HTTPS the model is, you and the server both know a secret, your "password" and then you... just tell them your secret each time to authenticate. That's a pretty good model if you're a ten year old playing forts out in the woods, but it's far below what we ought to be achieving for a service like this. It's true that this plaintext password authentication is normal for the web, which is basically Tim (Berners-Lee)'s fault but that doesn't magically make it a good idea, and it makes sense that GitHub doesn't want "Yes it's crap but it's no worse than the web" to be all they're delivering.

strogonoff 6y ago
Care to share any specific advantages, aside from the general notion of “appropriate security”?
- tialaramex 6y ago
  SSH authentication is a public key authentication so: The relying party (GitHub in this case) learn nothing secret. Your authentication credentials literally can't be stolen from GitHub because they don't have them, so you don't need to care about how well they try to protect them. A MITM learns nothing secret. If things go wrong and you somehow allow a MITM attack to occur, the MITM doesn't get durable credentials from you, once you are talking to GitHub not the MITM they're locked out, even though they watched you authenticate successfully, perhaps many times, they do not learn how to forge working credentials.
  - strogonoff 6y ago
    Thanks for elaborating. > If things go wrong and you somehow allow a MITM attack to occur I get the point, though perhaps the phrasing could do with a little less victim-shaming. How many of the times you were MITMed did you allow that to happen? Now count cases about which you still don’t know. > Your authentication credentials literally can't be stolen from GitHub because they don't have them, so you don't need to care about how well they try to protect them. To me, secret management on the side of an unsophisticated user is arguably of more worry than someone breaking into GitHub and stealing PATs. Consider if a user is casually contributing to documentation on GitHub using some Git client which forces them to supply an SSH key for authentication. Now there is more than one way things could go wrong, for example: 1) They use a key without a passphrase, and it is stored somewhere on their filesystem (perhaps under ~/.ssh, where ssh-keygen wants to place it by default) where any app with disk access can read it. Voila, a third party gets full access to their GitHub repositories. 2) They use a weak passphrase, reuse an old password for passphrase, or store the passphrase in plain text. Similar liability. Meanwhile, PAT is: long, auto-generated by GitHub (so one can’t reuse a password), shown only once, doesn’t make sense for the user to save, and the client can make sure to store it using a sound mechanism (e.g., Keychain on macOS). That said, a well-behaved user-friendly Git client could neutralize some of the downsides by taking care of generating a completely new, passphrase-protected SSH keypair under the hood, storing the passphrase and the private part reliably, and asking the user to add the public part to their GitHub account, each time it is set up on a new machine. I wonder how many clients go to such lengths.
    - tialaramex 6y ago
      > Meanwhile, PAT is: long, auto-generated by GitHub (so one can’t reuse a password), shown only once, doesn’t make sense for the user to save, and the client can make sure to store it using a sound mechanism (e.g., Keychain on macOS). Right, so, with a lot of extra hoop jumping GitHub have been able to special case HTTPS authentication for their site so that if you use these tokens it's only somewhat worse than what you get out of the box with SSH.