As has been mentioned (repeatedly) this obviously has no use for people using SSH. Indeed, the goal of this tool is explicitly to be helpful for cloud-hosted repositories in Visual Studio Team Services (formerly Visual Studio Online). This is helpful for teams that enforce two-factor authentication over HTTPS. The article assumes a bit of knowledge about this, but does indeed mention this:
> We ported this tool to Mac and Linux to simplify their authentication to remote Git repositories, in particular those hosted in Visual Studio Team Services (VSTS).
I'm curious why they don't add SSH support to Visual Studio Team Services then. :)
Edit: Apparently they are. But I still think it would've been better to layer two-factor auth on top of SSH keys, since that can be done securely in a 100% offline manner.
Perhaps it's just a cultural difference, since Windows doesn't ship with an SSH client?
These are (roughly) orthogonal issues: regardless of whether we support SSH or not, we are going to support HTTPS access to Git repositories. And if we support HTTPS, we must support two-factor authentication. A lot of organizations require this. (In fact, Microsoft itself requires this internally: our authentication to any internal web site uses 2FA.)
So Visual Studio Team Services must support HTTPS with two-factor authentication. This is awfully painful to use git core on the command-line without a credential manager to assist you.
Against a repository hosting service that lacks SSH or rather incentives HTTP(s) over SSH (Visual Studio Team Services, formerly Visual Studio Online), entering credentials is a problem with Git. 98% of Git users won't have this issue, but for those few it is probably the biggest, most annoying issue.
I am baffled why would they try to port this for Mac / Linux which already has SSH functionality built-in. It can make sense on Windows where there is no equivalent, by default.
Not everybody who uses a code hosting provider like GitHub or Microsoft Visual Studio Team Services uses SSH. Some people use HTTPS for whatever reason (outbound corporate firewalls and proxies, ease of setup, familiarity, or just personal preference). And I would recommend that those users further use two-factor authentication.
I like the idea of adding second-factor authentication to your Git credentials. But doing this using OAuth to a cloud service just seems like the wrong approach. Use SSH keys, and then either (a) set a good password on your key, or (b) store the key on a hardware token, like a Yubikey. [1]
I think the big problem here is that they're using HTTP(S) as a transport for Git. And there's just not very many options left for layering on extra security if you do that.
OAuth for SSH? What the hell are you guys doing? No, stop. Stop. Drop it. Go back to the drawing board and learn what SSH can do apart from password and public key auth (hint: Everything from challenge-response schemes to Kerberos).
It's not what they're doing (they don't have SSH at all), but is there anything wrong in using OAuth2 tokens to authenticate with SSH server? Conceptually, they're just another form of password (pre-shared secret).
> We ported this tool to Mac and Linux to simplify their authentication to remote Git repositories, in particular those hosted in Visual Studio Team Services (VSTS).