3 ms·

Which Git implementations, apart from reference CLI, support SSH key authentication? Isomorphic Git (which we use) doesn’t, for example. Not sure I particularl

Which Git implementations, apart from reference CLI, support SSH key authentication? Isomorphic Git (which we use) doesn’t, for example. Not sure I particularly want it to, either—such a feature would probably bring in a host of dependencies but not much to the table compared to a scoped PAT.

terinjokes 6y ago
Most should, or at least have it on the roadmap. There are many Git repositories, off GitHub, that are only accessible with SSH authentication.
- strogonoff 6y ago
  Really? Why? Seems like it would unnecessarily restrict the range of compatible clients.
nine_k 6y ago
I suppose GIT implementations are mostly transport-agnostic, and specific apps connect them to remote transports. E.g. JGit is widely used and has no notion of SSH keys, but GitBlit can serve a GIT repo over SSH using JGit, and JetBrains IDEs can access GIT repos served over SSH using some kind of pure Java SSH implementation (not sure which); I remember they used to use JGit, too.
tialaramex 6y ago
At least Jgit (the Java implementation) does this correctly. It seems very weird to do SSH at all without using SSH keys. The core SecSH (ie SSH 2) protocol design assumes you have SSH keys, offering password authentication only as an optional extra feature. Now of course the IETF does not have an enforcement arm, and I have seen implementations that don't work like that, but to me this is an obvious red flag, like a stub plugged in to stop the seat belt alarm going off, "I know that what I'm doing is very stupid, so I worked harder to do it anyway". OK then.
- strogonoff 6y ago
  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.

terinjokes 6y ago

Most should, or at least have it on the roadmap. There are many Git repositories, off GitHub, that are only accessible with SSH authentication.

strogonoff 6y ago
Really? Why? Seems like it would unnecessarily restrict the range of compatible clients.

nine_k 6y ago

I suppose GIT implementations are mostly transport-agnostic, and specific apps connect them to remote transports. E.g. JGit is widely used and has no notion of SSH keys, but GitBlit can serve a GIT repo over SSH using JGit, and JetBrains IDEs can access GIT repos served over SSH using some kind of pure Java SSH implementation (not sure which); I remember they used to use JGit, too.

tialaramex 6y ago

At least Jgit (the Java implementation) does this correctly. It seems very weird to do SSH at all without using SSH keys. The core SecSH (ie SSH 2) protocol design assumes you have SSH keys, offering password authentication only as an optional extra feature. Now of course the IETF does not have an enforcement arm, and I have seen implementations that don't work like that, but to me this is an obvious red flag, like a stub plugged in to stop the seat belt alarm going off, "I know that what I'm doing is very stupid, so I worked harder to do it anyway". OK then.

strogonoff 6y ago
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.