I think their goal was to make GitHub (and by extension git itself) more accessible to people who code, but are not familiar/comfortable enough with command line Unix or SSH to generate SSH keypairs. There are a lot of these people.
Although I agree that SSH keypairs feel more secure than a username/password, it would make setting up a new machine for development a lot easier than generating a new SSH keypair and adding it to my GitHub (or any other git server) account.
Couldn't the app use your username / password to connect to github the first time and then generate an SSH key pair which it would use from that point forward?
That seems like the best compromise of security and easy of use to me.
Comments
I think their goal was to make GitHub (and by extension git itself) more accessible to people who code, but are not familiar/comfortable enough with command line Unix or SSH to generate SSH keypairs. There are a lot of these people.
Although I agree that SSH keypairs feel more secure than a username/password, it would make setting up a new machine for development a lot easier than generating a new SSH keypair and adding it to my GitHub (or any other git server) account.
Couldn't the app use your username / password to connect to github the first time and then generate an SSH key pair which it would use from that point forward?
That seems like the best compromise of security and easy of use to me.
Then the client would only work easily with Github. That would be very sad for those of us who deploy Git repos on other servers than Github.
As it is, I'm pretty sure this is using standard HTTPS auth with Git, which is not that hard to support.
The client works fine with other Git servers, and uses your standard SSH keys.
"Death to the SSH key" applies only to GitHub interactions — getting a list of your repos, for example.
The new GitHub API actually supports Git operations authenticated via OAuth. Just throwing that out there.