Repository navigation
Allow configuring ssh host and optionally do account detection based on it #9740
Description
Activity
@titaniumtraveler : I want to follow up internally because I don't think exactly what
ghsupports in terms of SSH when working with repositories is well documented.pkg/ssh/ssh.goincli/go-ghwas designed to handle translating aliases like the ones above into hostnamespkg/repository/repository.goincli/go-ghis used to translate local repository fetch and push URLscontext/remote.goincli/clisimilarly handles translating local git remote URLs
Unfortunately
ghis oriented around GitHub hosts, not around user accounts. And while we do have multi-account support added, I'm unsure of the ramifications ofghattempting to manage SSH configuration for users.Additionally, did you mean to use the same
IdentityFilefor each host or were they intended to be separate?Unfortunately
ghis oriented around GitHub hosts, not around user accounts. And while we do have multi-account support added, I'm unsure of the ramifications ofghattempting to manage SSH configuration for users.That is sad, but I guess I should have guessed that based on the structure of
thehosts.ymlfile.@titaniumtraveler : I want to follow up internally because I don't think exactly what
ghsupports in terms of SSH when working with repositories is well documented.* [`pkg/ssh/ssh.go` in `cli/go-gh`](https://github.com/cli/go-gh/blob/trunk/pkg/ssh/ssh.go) was designed to handle translating aliases like the ones above into hostnames * [`pkg/repository/repository.go` in `cli/go-gh`](https://github.com/cli/go-gh/blob/71770357e0cb12867d3e3e288854c0aa09d440b7/pkg/repository/repository.go#L117-L158) is used to translate local repository fetch and push URLs * [`context/remote.go` in `cli/cli`](https://github.com/cli/cli/blob/c657cfac370ef33696cd19aaca187abbf6b3a9f9/context/remote.go#L105-L123) similarly handles translating local git remote URLsThese links are definitely helpful!
I kind of was planning to look how the multi-account-support is implemented
anyway, so having an entry point makes that easier!I am not too versed in
go, but I guess having the opportunity to learn
something is never a bad thing.Additionally, did you mean to use the same
IdentityFilefor each host or were they intended to be separate?No, that was not my intention. Thank you for pointing it out.
Fixed it. 😄
Describe the feature or problem you’d like to solve
I use multiple github accounts with isolated ssh-keys that are configured based
on the ssh-host.
My ssh config looks something like this:
While
ghworks mostly as expected with this setup, when cloning or forking arepo, the remotes use
[email protected]as ssh-host, which means I then have torename those to work with my system.
Proposed solution
It would be great if
ghsupported this use case by adding a setting toconfigure an ssh-host that is then being used for operations that
clone repos or add new remotes like
gh repo cloneorgh repo fork.(This new setting should be per-account, else that would be defeating the
purpose.)
Furthermore that ssh-host could then be used to automatically select the correct
user, which would make using multiple accounts pretty much seamless.
Additional context
Prior Art
gitea's CLIteahas the option to configure an ssh-host and uses that bothwhen cloning a new repo and for detecting which repository it is being called
from. (I'm not sure if they do account detection based on that though.)
Alternatives
Of cause this issue could be solved by wrapping
ghin a shellscript that aspre-execution hook selects the right account and as post-execution hook fixes up
the remotes, but that would likely cause some subtle bugs for more complex
operations like
gh pr createthat both create a fork and then push to thatfork.
So first party support would definitely be preferable.