[Kwpolska]

Solving the problem of having a personal and a work GitHub account is really trivial without any extra tools. All you need is a dedicated SSH key for that GitHub account. (And why would you have a password for a ssh key on your personal machine?)

~/.ssh/config

    Host github.com-work
     HostName github.com
     User git
     IdentityFile ~/.ssh/work_id_rsa
     IdentitiesOnly yes

~/.git/config

    [user]
    email = [e-mail]

    [remote "origin"]
    url = github.com-work:Work/Widget.git

[embedding-shape]

Which works for a while, until you have a bunch of projects under various identities.

In my main ~/.gitconfig I have:

  [includeIf "gitdir:/home/user/projects/embedding-shapes/"]
  path = /home/user/.gitconfig-embedding-shapes

Where basically `projects/` follow GitHub naming with $user/$repo, so I set the git identity based on all projects within that user, rather than repo-by-repo which would get cumbersome fast.

Then you just make sure you're in the right directory :)

[beaker52]

This. I’ve seen so many tools solving problems that already have solutions lately because LLMs allow people to run off and “fix” the problem their way before they can a chance to discover existing, more appropriate solutions.

The next step of this problem space is: “when I’m working on project X, I often forget to change my GitHub user with Gitas” so now they need direnv or something to switch it for them. The original solution foresaw this - so is far more complete that Gitas already _and_ built into git itself.

But, LLMs, so here we are, slowly drowning in a growing ocean of software built by the unaware.

[Terretta]

> built by the unaware

awash in bliss

[accoil]

I use that approach. I also make sure to not set the [user] section in my main config (and only in the included files). That way if I'm operating outside of one of my user directories git commit fails due to having no user details.

[arccy]

If you don't want to bother with directories or want to use https instead of ssh, you can do remote url based dispatch in your gitconfig:

    [credential "https://github.com/org1"]
      useHttpPath = true
      helper =
      helper = /path/to/auth.sh user1
    [includeIf "hasconfig:remote.*.url:https//github.com/org1/**"]
      path = user1.gitconfig
      ; set name / email in user1.gitconfig

where auth.sh is something that can produce the right token for the given user, e.g.

    #!/bin/bash
    echo "username=$1"
    echo "password=$(gh auth token --user $1)"

[xn]

Are there any good reasons to use multiple GitHub user accounts? GitHub organization membership and permissions are well designed in my experience, negating the need for multiple user accounts.

[StarlaAtNight]

Consultants or professional services folks will be working in their company’s GitHub account and several clients. Requires managing lots of git/GitHub accounts

[Terretta]

Simplifying for brevity* -- there are three levels in the GitHub entity:

  - accounts (personal)
  - orgs (companies, directories, teams, roles etc.)
  - enterprises (sets of orgs)

Even with enterprise SSO, the initial connect to GH can (is typically) "you" (just as you have the same driver license to show at the front desk when registering to visit a secured firm or random hotel), then you elevate "you" into the org through SSO, and what policies apply to you via your org can be 'governed' at the enterprise.

The idea behind this model is that no, you don't have to manage lots of those as you, you're just you, and each of those you aim to use has an elevation that entity controls instead of you controlling it.

This ultimately results in way less key material floating around, and you losing, leaking, or lousing up your own GH cred doesn't auto-give an attacker the SSO elevation.

• • •

Not incidentally, I have a slew of "accounts" given to me by companies that don't bother to make an org, they just invite individuals to repos or make individual accounts for their repo. I suppose it's cheaper in the short run. In the long run, these accounts are 90% still left active years to (no kidding) decade+ later. Seems a better idea to "don't do this." If you're a company, be an org.

---

* Expanded for more depth: https://docs.github.com/en/get-started/learning-about-github...

[embedding-shape]

> Are there any good reasons to use multiple GitHub user accounts?

Is there any good reasons not to separate what you work on into multiple GitHub accounts? Not to mention some people don't want all their projects attached to one profile, some people also develop in their free-time, and don't want to mix freetime/work projects under the same user account, for multiple reasons.

[Hamuko]

I use a pseudonym during my free time, so yes. Also my employer is requiring us to use company-specific GitHub accounts, so the decision is out of my hands anyway.

[magicalhippo]

We went with that primarily due to requiring SSO and because we might want employees to interact with other projects with the company hat on.

If they used their personal account for both, it could be unclear if they speak on behalf of our company or not.

[jimmydoe]

A why not

B if you ever be in a company using the half baked GitHub hosted enterprise….

[hrpnk]

The host shenanigans are simpler addressed with `git config core.sshCommand` which overrides the default key and selects the desired one on a per repository level.

source: https://erik.doernenburg.com/2017/12/using-multiple-github-a...

[CamJN]

Doesn’t work for cloning, obviously. The way I handle it is I have ssh look at the hostname and path passed by git and decide which identity to use. This is very easy in openssh 10.0+ using the command matching syntax, and more difficult to varying degrees on earlier versions of openssh, depending on your OS.

[OrderlyTiamat]

> (And why would you have a password for a ssh key on your personal machine?)

You're presumably joking? If not, could you elaborate?

[PunchyHamster]

well if you have encrypted storage and already need password to get to it, secondary password is of little value

Tho I prefer to just use hardware key for ssh

[craftkiller]

> well if you have encrypted storage and already need password to get to it, secondary password is of little value

That's only true when your machine is powered off. If an attacker manages to yank files from your disk while it is running, that ssh-key password is the difference between "they stole my ssh key" and "they stole worthless random data".

> use hardware key for ssh

That's the real solution. I don't understand why people still store ssh keys on disk when hardware keys are simple, easy, and significantly more secure.

[bubblewand]

> That's the real solution. I don't understand why people still store ssh keys on disk when hardware keys are simple, easy, and significantly more secure.

At work, every place big enough to maybe care about this was so “enterprisey” and “cloudy” that I almost never use/used ssh anyway, even with tons of Linux systems all over the place. Pretty much only to talk to GitHub.

I lose stuff all the time. The idea of these things gives me anxiety. The first time I lost 15 minutes figuring out where I put my hardware key, before I could ssh in to do 20 seconds of running commands, I’d back out of the whole project and return to using a file on disk, guaranteed.

Files on disk are free, hardware keys cost money.

25 years as a backend-heavy programmer, sysadmin, and devops-sort (sometimes all at once, lol). I’ve still never even touched one of these devices, and have only rarely seen one.

[craftkiller]

> I lose stuff all the time

Do you lose your keys? I just keep my main yubikey on my keychain. Never gets lost or else I'd be homeless. I keep a 2nd backup key in a secure place just in case, so I don't get locked out of my accounts if I get struck by lightning.

> hardware keys cost money

Barely. You can get u2f keys for $10-$20 which are usable with ssh. My yubikeys were $50 each (I have 2, one main key and one backup) which adds up to $100 but yubikeys are built like tanks, they'll last forever. I've had mine for the past 7 years and I have no reason to replace them. That's only $14/year so far for the pair of keys. Totally worth it for the knowledge that I could load every virus/trojan/keylogger known to man onto my computer and they still would be completely unable to steal my ssh+pgp keys.

[bubblewand]

> Do you lose your keys?

It routinely takes me two to ten minutes to track them down, yeah. Every now and then, longer.

[rzzzt]

ssh-agent will also be happy to provide the key to git after an initial unlock with the passphrase.

[fastasucan]

>well if you have encrypted storage and already need password to get to it, secondary password is of little value

This is not true at all though. What about when you are logged into your computer.

[jimmydoe]

For Claude Code users:

- using alternative host is not supported when roaming between local and cloud, fix is to add another origin you don’t use but use GitHub.com url

- CC uses gh command, which still needs account switch, this can be solved by add the switch to CC hook.

[adithyassekhar]

Is this that dropbox moment again? Anyway on Windows I keep a separate work and personal profile and GitHub auth doesn't go between them.

[trueismywork]

Have different PCs