Add SSH key generation & uploading to gh auth login flow

[mislav]

When "SSH" protocol is selected during gh auth login interactive mode, this offers to generate and upload an SSH key to the user's GitHub account.

The order of gh auth login questions was reshuffled to accommodate the new flow and to know beforehand which OAuth scopes to request (workflow for HTTPS mode, admin:public_key for SSH mode).

The new flow when no SSH keys exist locally:

$ gh auth login -h github.com
? What is your preferred protocol for Git operations?  [Use arrows to move, type to filter]
  HTTPS
> SSH
? Generate a new SSH key to add to your GitHub account? (Y/n)
? Enter the passphrase for your new SSH key *****
? How would you like to authenticate GitHub CLI?  [Use arrows to move, type to filter]
> Login with a web browser
  Paste an authentication token

! First copy your one-time code: ****-****
- Press Enter to open github.com in your browser...
✓ Authentication complete. Press Enter to continue...

- gh config set -h github.com git_protocol ssh
✓ Configured git protocol
✓ Uploaded the SSH key to your GitHub account: /Users/mislav/.ssh/id_ed25519.pub
✓ Logged in as mislav

The new flow when existing ~/.ssh/*.pub files (SSH public keys) were found locally:

$ gh auth login -h github.com
? What is your preferred protocol for Git operations?  [Use arrows to move, type to filter]
  HTTPS
> SSH
? Upload your SSH public key to your GitHub account?  [Use arrows to move, type to filter]
> /Users/mislav/.ssh/id_ed25519.pub
  Skip
? How would you like to authenticate GitHub CLI? Login with a web browser

! First copy your one-time code: ****-****
- Press Enter to open github.com in your browser...
✓ Authentication complete. Press Enter to continue...

- gh config set -h github.com git_protocol ssh
✓ Configured git protocol
✓ Uploaded the SSH key to your GitHub account: /Users/mislav/.ssh/id_ed25519.pub
✓ Logged in as mislav

Under the hood:

• This approach goes out of its way to request only the minimum OAuth scopes necessary
• We only offer to generate a SSH key when ssh-keygen is available on the system. On Windows, we try to locate ssh-keygen within the Git for Windows installation.
• We select the ed25519 algorithm when generating SSH keys, which is also recommended by GitHub help. Some older ssh-keygen implementations might not support ed25519.
• We avoid ever overwriting any existing key under the ~/.ssh directory.
• Trying to re-upload an SSH key that is already in the user's account will succeed silently instead of yielding a HTTP 422 error.
• Removes the need for overridable shared.ClientFromCfg function
  • Fixes the correct User-Agent header being used for API requests during gh auth

Questions for the team:

• Does the prompt order & phrasing make sense?
• Should gh auth refresh also have any of this functionality?

TODO:

• Test coverage for ssh-keygen flow

Fixes #2627

[vilmibm]

This is great ✨ marking request change for my one incredibly minor request about passphrases.

[vilmibm]

should this be deleted?

[mislav]

Yes, good call. I was on the fence about leaving it in, but it's entirely optional for SSH keys in general and adds yet another prompt in this command that already has a dozen prompts. Best to avoid it.

[ampinsk]

Re: this part of the existing ssh key flow:

? Upload your SSH public key to your GitHub account?  [Use arrows to move, type to filter]
> /Users/mislav/.ssh/id_ed25519.pub
  Skip

Should we offer to let you create a new one here? Or is that unnecessary?

[mislav]

Should we offer to let you create a new one here? Or is that unnecessary?

That's a great idea which I hadn't at all considered. When the user already has some SSH keys of their own, I assumed that they wanted to reuse one of them for GitHub because that's what I would have done, but it's entirely possible that they might want to generate a new one for GitHub.

Here's a catch though. Since some keys already exist, when generating a new one we'd have to also ask the person to name their new key on disk (to avoid clashes with existing keys). And, if the user names their key something other than id_dsa, id_ecdsa, id_ed25519, or id_rsa (i.e. the default key names), then they would have to add additional lines to their ~/.ssh/config to wire up their key for use with GitHub:

Host github.com
  IdentityFile ~/.ssh/<my-new-key>

We could either tell the user they have to do this, or do it for them, but I'm a bit wary of editing people's ~/.ssh/config. @vilmibm do you have opinions on how best to handle this?

[vilmibm]

@mislav @ampinsk

Offering to generate new keys at that step makes sense but I think can be punted on. The kind of folks that tend to generate new keypairs per remote are more security conscious and I feel like our SSH helpers here are for people less familiar with SSH. Given that and the complexities you mentioned (ensuring we don't overwrite and potentially handling the ssh config) I think we should leave things as they are in the PR.

Regarding updating the SSH config, the cleanest way that I can think of is converting a user's ssh config to .ssh/config.d and adding a file there but I'd be uncomfortable with that level of manipulation of a user's .ssh directory.

[vilmibm]

💯