Git and ssh

Every container opendevhub starts (the project's and each worktree's own) is set up for git when it starts or is reconnected.

IdentityCopy Anchor Link

user.name and user.email are copied from git on your machine, read in the project folder so includeIf identities apply. They are only set when the container has none; values it already has are kept.

ssh-agentCopy Anchor Link

Your agent (SSH_AUTH_SOCK) is forwarded into the container at /tmp/opendevhub-ssh-agent.sock through the relay, so git fetch, git pull, git push and private git dependencies work over ssh.

• opencode gets SSH_AUTH_SOCK, and git's core.sshCommand uses the socket so terminals and VS Code use it too (unless the container sets its own core.sshCommand).
• The agent is only reachable while opendevhub runs. When it isn't, git falls back to the shell's own SSH_AUTH_SOCK (VS Code's forwarded agent, for example).
• Your private keys never enter the container, but anything running in it can use them while the agent is forwarded.

The checkout page shows whether the agent is forwarded.

Load your key into the agentCopy Anchor Link

The forwarded agent is the container's only way to your key, so the agent on your machine has to hold it. ssh on your machine can read ~/.ssh/id_ed25519 from disk and work with an empty agent; the container can't. Check with:

ssh-add -l          # "The agent has no identities." means it's empty
ssh-add ~/.ssh/id_ed25519

gpg-agent keeps keys added this way across restarts (they're listed in ~/.gnupg/sshcontrol). OpenSSH's ssh-agent forgets them when it exits; set AddKeysToAgent yes in ~/.ssh/config so the first ssh you run loads the key again:

Host *
  AddKeysToAgent yes

With home-manager, that's programs.ssh.settings."*".AddKeysToAgent = "yes"; (with enableDefaultConfig = false, the "*" block isn't there unless you add it).

When the agent holds no keys, the checkout page shows ssh-agent has no keys and the log says ssh-agent: forwarded, but the ssh-agent on this machine holds no keys. It clears by itself after ssh-add; nothing needs restarting.

Your ssh config stays on your machineCopy Anchor Link

~/.ssh/config isn't copied into containers. User, port and host from the remote URL are what the container uses (ssh://git@forge.example.com:2222/team/app.git says all three), so a Host entry that sets User or Port only helps on your machine. Remotes that rely on an alias don't resolve in containers; see Known limitations.

known_hostsCopy Anchor Link

For each ssh remote of the project, the matching entries from your ~/.ssh/known_hosts are added to the container's. Hosts you haven't connected to from your machine are skipped; the log says to ssh to them once.

Turn forwarding offCopy Anchor Link

Whether your keys go into a project's containers is your call, so it's set in ~/.config/opendevhub/config.json, not in the repo (sshAgent in devcontainer.json is ignored):

{ "projects": { "/path/to/repo": { "sshAgent": false } } }

It takes effect the next time the container starts or opendevhub restarts. An opencode server started before forwarding was set up picks up SSH_AUTH_SOCK after Restart opencode.

TroubleshootingCopy Anchor Link

git@host: Permission denied (publickey) in a container means ssh reached the server but had no key it accepted:

1. Check the badge on the checkout page. ssh-agent unavailable names the reason; ssh-agent has no keys means ssh-add on your machine (see above).
2. Run ssh-add -l on your machine and make sure the key the forge knows is listed.
3. In the container, SSH_AUTH_SOCK=/tmp/opendevhub-ssh-agent.sock ssh-add -l should list the same keys. If it can't reach the agent, opendevhub isn't running or the container was started before forwarding was set up; restart it from the dashboard.
4. Check git config --global core.sshCommand in the container. If the container sets its own, opendevhub leaves it alone and it must use the forwarded agent itself.

Host key verification failed means the host isn't in the container's known_hosts: ssh to it once from your machine, then restart the container.