git and gh CLI in a dev container

Create a key for the second identity

If you already have a personal SSH key on this machine, skip ahead. Otherwise:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_personal -C "personal"

Add the public half to GitHub under Settings → SSH and GPG keys, on the personal account.

cat ~/.ssh/id_ed25519_personal.pub

Teach ssh which key belongs to which account

Give the second identity its own Host alias, and tell ssh to use only the key you named. Both halves matter.

Change ~/.ssh/id_ed25519 below to whatever your existing work key actually is. Adding IdentitiesOnly yes makes that line binding, so a wrong path there locks you out of your work repositories.

Host *
  IgnoreUnknown UseKeychain

Host github.com
  User git
  AddKeysToAgent yes
  UseKeychain yes
  IdentitiesOnly yes
  IdentityFile ~/.ssh/id_ed25519

Host github-personal
  HostName github.com
  User git
  AddKeysToAgent yes
  UseKeychain yes
  IdentitiesOnly yes
  IdentityFile ~/.ssh/id_ed25519_personal

Load the new key into the agent once, on the host:

ssh -T github-personal

This matters more than it looks. The container gets its keys from the forwarded agent, and the agent only holds what has been added to it. AddKeysToAgent yes adds a key the first time you use it — on the host. Until that has happened at least once, there is nothing to forward and git inside the container fails with Permission denied (publickey).

Then point the repository at the alias, and git picks the right key every time:

git remote set-url origin github-personal:you/your-project.git

If the project is not yours, fork it first — you cannot push to someone else’s repository, so origin has to be your copy:

gh repo fork owner/project --clone
git remote set-url origin github-personal:you/project.git

gh repo fork --clone sets origin to your fork and upstream to the original, which is what gh pr create expects. Run it inside the container, where gh is already authenticated as the personal account.

Set the matching identity on the repo too, so commits are attributed correctly:

git config user.name "Your Name"
git config user.email "you@personal.example"

Create a token for gh

Which kind of token you need depends on whose repository you are working on, and this is the one place where GitHub’s newer fine-grained tokens will quietly not do the job.

GraphQL: Resource not accessible by personal access token (createPullRequest)

Contributing to other people’s projects — github.com/settings/tokens/new, signed in as the personal account. Tick public_repo, which covers pushing to your forks and opening pull requests anywhere public. Use the broader repo only if you also work on private repositories, and add workflow only if you edit files under .github/workflows/.

Working on your own repositories — github.com/settings/personal-access-tokens/new gives you something much tighter:

Either way, give it an expiry you will actually notice — 90 days is a reasonable default — and copy the value. GitHub shows it once.

Store the token on the host

Never in the repo, never in a .env. Put it in the machine’s own secret store.

Pick your platform below — the tabs stay in sync for the rest of the page. On Remote SSH, “the host” means the remote machine, not your laptop.

security add-generic-password -a personal -s gh-token-personal -U -w

security find-generic-password -a personal -s gh-token-personal -w

sudo apt install libsecret-tools

secret-tool store --label='gh-token-personal' \
  account personal service gh-token-personal

secret-tool lookup account personal service gh-token-personal

sudo apt install pass

gpg --quick-generate-key "you@personal.example" default default never
pass init you@personal.example

pass insert personal/gh-token
pass show personal/gh-token

default-cache-ttl 34560000
max-cache-ttl 34560000

Export it for VS Code only

At startup VS Code spawns an interactive login shell — $SHELL -i -l -c — purely to capture your environment, and sets VSCODE_RESOLVING_ENVIRONMENT=1 while doing it.

Hang the export off that variable and the token exists in exactly one transient process, and in no terminal you ever type into.

if [[ -n $VSCODE_RESOLVING_ENVIRONMENT ]]; then
  export PERSONAL_GH_TOKEN="$(security find-generic-password \
    -a personal -s gh-token-personal -w 2>/dev/null)"
fi

if [[ -n $VSCODE_RESOLVING_ENVIRONMENT ]]; then
  export PERSONAL_GH_TOKEN="$(secret-tool lookup \
    account personal service gh-token-personal 2>/dev/null)"
fi

if [[ -n $VSCODE_RESOLVING_ENVIRONMENT ]]; then
  export PERSONAL_GH_TOKEN="$(pass show personal/gh-token 2>/dev/null)"
fi

Two details worth knowing. The 2>/dev/null is not cosmetic: anything written to stderr during environment resolution can corrupt what VS Code parses back. And keep the block fast — VS Code gives shell resolution ten seconds before it gives up with “Unable to resolve your shell environment in a reasonable time”, and when it gives up your token is simply absent.

Using bash, the same block goes in ~/.bashrc; VS Code runs the shell as both interactive and login, so make sure your ~/.bash_profile sources ~/.bashrc, as Ubuntu’s default already does. For fish, use test -n "$VSCODE_RESOLVING_ENVIRONMENT" in ~/.config/fish/config.fish.

Wire it into the container

Two things go in: the token as GH_TOKEN, and your ~/.ssh folder mounted read-only so ssh can read the config and pick the right key.

How you declare them depends on how the dev container is built. Compose-based containers put both in docker-compose.yml; the simpler image- or Dockerfile-based ones put them straight in devcontainer.json.

services:
  dev:
    image: mcr.microsoft.com/devcontainers/base:ubuntu
    user: vscode
    environment:
      - GH_TOKEN=${PERSONAL_GH_TOKEN:-}
    volumes:
      - ..:/workspaces/your-project:cached
      - type: bind
        source: ${HOME}/.ssh
        target: /home/vscode/.ssh
        read_only: true
    command: sleep infinity

{
  "name": "your-project",
  "dockerComposeFile": "docker-compose.yml",
  "service": "dev",
  "workspaceFolder": "/workspaces/your-project"
}

{
  "name": "your-project",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "remoteUser": "vscode",
  "remoteEnv": {
    "GH_TOKEN": "${localEnv:PERSONAL_GH_TOKEN}"
  },
  "mounts": [
    "source=${localEnv:HOME}/.ssh,target=/home/vscode/.ssh,type=bind,readonly"
  ]
}

A tighter SSH mount

Mounting the whole ~/.ssh folder is the shortest path, not the tightest one.

Your private keys do not travel through that mount. VS Code forwards the host ssh-agent automatically and the agent does the signing; the mount exists only so ssh can read ~/.ssh/config, because configuration is not part of the agent protocol. The keys are along for the ride, readable by anything in the container, for no reason.

Two ways to narrow it. Both keep the forwarded agent exactly as it is.

Option 1 — mount only the two files ssh actually reads. config to resolve the alias, known_hosts so GitHub’s host key is already trusted:

services:
  dev:
    image: mcr.microsoft.com/devcontainers/base:ubuntu
    user: vscode
    environment:
      - GH_TOKEN=${PERSONAL_GH_TOKEN:-}
    volumes:
      - ..:/workspaces/your-project:cached
      - type: bind
        source: ${HOME}/.ssh/config
        target: /home/vscode/.ssh/config
        read_only: true
      - type: bind
        source: ${HOME}/.ssh/known_hosts
        target: /home/vscode/.ssh/known_hosts
        read_only: true
    command: sleep infinity

{
  "name": "your-project",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "remoteUser": "vscode",
  "remoteEnv": {
    "GH_TOKEN": "${localEnv:PERSONAL_GH_TOKEN}"
  },
  "mounts": [
    "source=${localEnv:HOME}/.ssh/config,target=/home/vscode/.ssh/config,type=bind,readonly",
    "source=${localEnv:HOME}/.ssh/known_hosts,target=/home/vscode/.ssh/known_hosts,type=bind,readonly"
  ]
}

One line changed, private keys never exposed. Both files must already exist on the host or the bind fails — known_hosts does if you have ever connected to GitHub from this machine.

Option 2 — drop the ssh config and tell git directly. Set the key per repository instead:

git config core.sshCommand \
  'ssh -i ~/.ssh/id_ed25519_personal.pub -o IdentitiesOnly=yes'

That lands in .git/config, which is already inside the bind-mounted workspace, so it reaches the container with no extra configuration. Leave the ~ unexpanded — git runs the command through a shell, and the same value then works on the host and in the container.

The part that looks wrong is -i pointing at a public key. It works because the private half is in the forwarded agent: ssh uses the public key to choose which agent identity to offer, and the agent signs. IdentitiesOnly yes stops it offering anything else.

The container still needs to read that .pub file and known_hosts. Both are public, so mount just those two:

    volumes:
      - ..:/workspaces/your-project:cached
      - type: bind
        source: ${HOME}/.ssh/id_ed25519_personal.pub
        target: /home/vscode/.ssh/id_ed25519_personal.pub
        read_only: true
      - type: bind
        source: ${HOME}/.ssh/known_hosts
        target: /home/vscode/.ssh/known_hosts
        read_only: true

  "mounts": [
    "source=${localEnv:HOME}/.ssh/id_ed25519_personal.pub,target=/home/vscode/.ssh/id_ed25519_personal.pub,type=bind,readonly",
    "source=${localEnv:HOME}/.ssh/known_hosts,target=/home/vscode/.ssh/known_hosts,type=bind,readonly"
  ]

The trade-off is scope: core.sshCommand covers git and nothing else, so ssh -T github-personal stops working as a check inside the container. Use git ls-remote instead.

--mount type=bind,source=${SSH_AUTH_SOCK},target=/ssh-agent \
--remote-env SSH_AUTH_SOCK=/ssh-agent

Check both halves

Quit VS Code completely and relaunch, then open a terminal in the container and test each identity separately.

The token, which is what gh uses:

echo "${GH_TOKEN:+set}"
gh auth status

The first prints set or nothing, so you confirm it arrived without putting the secret on screen. The second should name the personal account:

github.com
  ✓ Logged in to github.com account you (GH_TOKEN)
  - Active account: true
  - Token: ghp_************************************

The parenthesis after the account name is the useful part. GH_TOKEN means it picked up the environment variable; keyring or oauth_token means it found a stored login instead, and you are about to act as the wrong account.

The key, which is what git uses — always through the alias:

ssh -T github-personal

Hi you! You've successfully authenticated, but GitHub does not
provide shell access.

The name in the greeting is the account that key belongs to. If it is the wrong one, check git remote -v — the remote has to use the alias, not git@github.com.

Finally, confirm the two are genuinely independent by checking git separately:

git remote -v
git config user.email