Repository navigation
Allow configuring ssh host and optionally do account detection based on it #9740
Description
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:
Host gh1
User git
HostName github.com
IdentityFile <path-to-the-ssh-key-gh1>
Host gh2
User git
HostName github.com
IdentityFile <path-to-the-ssh-key-gh2>
Host gh3
User git
HostName github.com
IdentityFile <path-to-the-ssh-key-gh3>While gh works mostly as expected with this setup, when cloning or forking a
repo, the remotes use [email protected] as ssh-host, which means I then have to
rename those to work with my system.
Proposed solution
It would be great if gh supported this use case by adding a setting to
configure an ssh-host that is then being used for operations that
clone repos or add new remotes like gh repo clone or gh 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 CLI tea has the option to configure an ssh-host and uses that both
when 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 gh in a shellscript that as
pre-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 create that both create a fork and then push to that
fork.
So first party support would definitely be preferable.
Activity
andyfeller commentedon Oct 15, 2024
@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 URLsUnfortunately
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?titaniumtraveler commentedon Oct 18, 2024
That is sad, but I guess I should have guessed that based on the structure of
the
hosts.ymlfile.These 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 learnsomething is never a bad thing.
No, that was not my intention. Thank you for pointing it out.
Fixed it. 😄
kako654 commentedon Nov 14, 2024
barnuri commentedon Oct 15, 2026
Until this lands natively, I added this to a small gh wrapper I maintain: https://github.com/barnuri/ghx (v0.1.4+)
With ssh host aliases like
Host gh1/Host gh2in~/.ssh/config, map each alias to a gh account in~/.config/ghx/config.yaml:In a repo cloned as
git@gh1:org/repo.git, ghx reads the host fromgit remote get-url originand runs the realghwith that account's token (gh auth token --user <login>). It never callsgh auth switch, so terminals in different repos keep their own account. All gh commands, flags and extensions pass through unchanged. Details: https://github.com/barnuri/ghx#ssh-host-aliases-ssh_hosts