Add SSH key generation & uploading to gh auth login flow#2892
Conversation
We now request it conditionally only for "HTTPS" login flow
vilmibm
left a comment
There was a problem hiding this comment.
This is great ✨ marking request change for my one incredibly minor request about passphrases.
pkg/cmd/auth/shared/ssh_keys.go
Outdated
| // err = prompt.SurveyAskOne(&survey.Input{ | ||
| // Message: "Enter the label for your new SSH key", | ||
| // }, &sshLabel) | ||
| // if err != nil { | ||
| // return "", fmt.Errorf("could not prompt: %w", err) | ||
| // } |
There was a problem hiding this comment.
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.
|
Re: this part of the existing ssh key flow: Should we offer to let you create a new one here? Or is that unnecessary? |
Co-authored-by: Amanda Pinsker <ampinsk@github.com>
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 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 |
|
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 |
When "SSH" protocol is selected during
gh auth logininteractive mode, this offers to generate and upload an SSH key to the user's GitHub account.The order of
gh auth loginquestions was reshuffled to accommodate the new flow and to know beforehand which OAuth scopes to request (workflowfor HTTPS mode,admin:public_keyfor SSH mode).The new flow when no SSH keys exist locally:
The new flow when existing
~/.ssh/*.pubfiles (SSH public keys) were found locally:Under the hood:
ssh-keygenis available on the system. On Windows, we try to locatessh-keygenwithin the Git for Windows installation.ed25519algorithm when generating SSH keys, which is also recommended by GitHub help. Some olderssh-keygenimplementations might not supported25519.~/.sshdirectory.shared.ClientFromCfgfunctionUser-Agentheader being used for API requests duringgh authQuestions for the team:
gh auth refreshalso have any of this functionality?TODO:
ssh-keygenflowFixes #2627