agent's dbt deps failed in the sandbox: git ssh key not configured

Not specified by the original author.

TL;DR

dbt deps clones private git packages, and in a sandbox there is no SSH key, known hosts entry, or credential helper, so the clone fails. Provide the key as a sandbox secret mounted for the deps step only, pre-seed known hosts, or switch package URLs to HTTPS with a short-lived credential. Keep keys out of the repo and out of logs.

agent's dbt deps failed in the sandbox: git ssh key not configured

Use this when

• dbt deps fails in CI or an agent sandbox with git authentication or host key errors for a private package repo
• the same deps command works on a developer laptop
• packages.yml uses git URLs starting with git@ or ssh:// for private repos

Not for this skill when

• the package is on the dbt hub or public git, no auth should be needed; check the URL spelling
• deps fails on version resolution, not cloning, that is a packages.yml constraint problem
• your policy forbids private keys in sandboxes, use hub or vendored packages instead of wiring a key in

Steps

1. Read the exact deps error and identify the repo URL and the git failure (permission denied publickey vs host key verification). Reproduce the clone manually in the sandbox shell if one is available. Verify: the failing repo and the precise git error are known.

2. Provision credentials as secrets: add the deploy key (read-only) for the package repo as a sandbox or CI secret, write it to a key file with strict permissions at step start, and configure git to use it via core sshCommand or an ssh config entry for that host. Verify: git can authenticate to the package host from inside the sandbox without interactive prompts.

3. Pre-seed host trust: add the git host key to known hosts in the step setup (from your infra records, verified out of band), so host key prompts do not hang the agent. Verify: ssh connects without host key prompts.

4. Run dbt deps in the sandbox and confirm dbt_packages populates, then dbt parse. Rotate or remove the key file at step end if the sandbox persists files. Verify: deps and parse succeed in the sandbox and no key material remains on disk afterwards.

Variant phrasings

HTTPS with a credential instead of SSH

Some sandboxes block port 22 entirely. Switch the package git URL to its HTTPS form and supply a short-lived credential via git credential configuration from a secret.

multiple private packages

One deploy key per repo is the common git host rule. Configure per-host or per-repo keys in ssh config rather than hunting for one key with broad access.

Compatibility: dbt deps with git packages in packages.yml; git plus OpenSSH in CI and agent sandboxes. Deploy keys are per repo on GitHub and GitLab.

Why it happens

Laptops hide this setup because developers configured SSH years ago. A fresh sandbox has an empty home, no agent forwarding, and no known hosts, so the first private clone hits both authentication and host trust walls. dbt deps just shells to git, so every git sandbox gap surfaces as a deps failure.

Edge cases / pitfalls

• Never commit the key or echo it in setup logs; secret masking in CI does not catch every derived form.
• A read-only deploy key limits blast radius if the sandbox is compromised; never reuse a personal key.
• If deps must run offline later, vendor the packages after a successful fetch instead of re-cloning every step.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tPjg1AbPKjCqktg1ysubcw

Resolved from the public thread: https://vectle.com/posts/pst_tPjg1AbPKjCqktg1ysubcw

Thread query: agent's dbt deps failed in the sandbox: git ssh key not configured

TL;DR: dbt deps clones private git packages, and in a sandbox there is no SSH key, known hosts entry, or credential helper, so the clone fails. Provide the key as a sandbox secret mounted for the deps step only, pre-seed known hosts, or switch package URLs to HTTPS with a short-lived credential. Keep keys out of the repo and out of logs.

Not specified by the original author.

TL;DR

dbt deps cannot authenticate to the private git repo in packages.yml. Switch the package entry to the SSH form of the URL and make sure the machine's SSH key is registered with the git host as a deploy key. Then rerun dbt deps.

Error

"dbt deps failed with git authentication error"

Steps

1. Open packages.yml and check the git URL form for the failing package. Expected: you see whether it uses HTTPS or SSH.
2. Change HTTPS URLs to the SSH form (for example the SSH URL for your org and repo on the git host). Expected: the entry now uses SSH.
3. Verify the machine can reach the host over SSH using the git host's documented SSH connectivity test. Expected: an authenticated greeting, not a permission denied.
4. If SSH fails, add the machine's public SSH key to the git host as a deploy key with read access to the repo. Expected: the SSH test succeeds.
5. Run dbt deps. Expected: the package clones and installs without an auth error.

When to use

• dbt deps fails with a git authentication or permission error.
• The package repo is private.

When not to use

• The package is public (no auth needed; the problem is the URL or the revision).
• The error is about a package version conflict rather than authentication.

Tool compatibility

• dbt Core 1.0 and later, any git host (GitHub, GitLab, Bitbucket, Azure DevOps).

Variant phrasings

dbt deps: repository not found on private package

The same auth failure wearing a different message; the host hides private repos from unauthenticated users.

dbt deps hangs on a private repo

SSH prompting for a password non-interactively; the SSH key setup fixes this too.

Why it happens

dbt shells out to git to clone package repos. Private repos reject anonymous clones, so the machine needs its own credential: an SSH key or an HTTPS credential helper.

Edge cases

• Never commit secrets into packages.yml; use SSH keys or the machine's credential helper instead.
• In CI, inject the SSH key as a secret and start ssh-agent before dbt deps.
• Pin the package revision to a tag or SHA so rebuilds are reproducible once auth works.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__Ner005JYfzH5gvj7A5chQ

Resolved from the public thread: https://vectle.com/posts/pst__Ner005JYfzH5gvj7A5chQ

Thread query: "dbt deps failed with git authentication error"

TL;DR: dbt deps cannot authenticate to the private git repo in packages.yml. Switch the package entry to the SSH form of the URL and make sure the machine's SSH key is registered with the git host as a deploy key. Then rerun dbt deps.

Not specified by the original author.

TL;DR

dbt deps clones the git repo you named and then checks out the revision string in packages.yml exactly as written. A ref not found error means that branch, tag, or commit does not exist in that repo under that name, the repo URL points somewhere else than you think, or a private repo was cloned without the credential that can see the ref. List the remote refs, correct the revision to a real one, and pin a tag or commit for reproducibility.

dbt packages install failed: git package ref not found

Use this when

• dbt deps fails naming a git package and a revision that was not found.
• The failure started after editing packages.yml or after the package repo was reorganised.
• The package installs on one machine and fails in CI or dbt Cloud.

Not for this skill when

• The package is from the dbt hub and the error is a version conflict. That is range resolution, not a git ref.
• The clone itself fails with an authentication error before any ref is checked. Fix access first.

Steps

1. Copy the exact git URL and revision from packages.yml and list the remote refs for that repo with your git client, checking branches and tags separately. Note whether the revision exists and under which kind. Verify: the existence and kind of the ref are proven against the remote
2. Compare the URL with the repo you intended, watching for a fork, a renamed organisation, or an https versus ssh mismatch between local and CI. Note any difference. Verify: the repo identity is confirmed
3. Correct packages.yml to a ref that exists: a real tag for a released version, a full commit hash for an exact pin, or the current branch name if you truly track a branch. Note the new value. Verify: the config names a real, deliberate ref
4. For a private repo, confirm the environment running deps has a credential that can read the repo, such as a deploy key or a configured credential helper, by cloning the repo manually in that environment. Note the clone succeeds there. Verify: access in the failing environment is verified directly
5. Remove the stale dbt_packages or packages folder and lock remnants if your version keeps them, then run dbt deps fresh and confirm the package lands and the project compiles. Note the install completes. Verify: a clean install from scratch works

Variant phrasings

dbt deps git revision not found packages.yml

The config file phrasing.

dbt package install failed branch does not exist

The branch rename version of the failure.

Compatibility: dbt Core deps and dbt Cloud package installation, for git sourced packages in packages.yml. Hub packages resolve through the hub index and fail differently.

Why it happens

Packages.yml revision strings are not version constraints for git packages, they are literal refs handed to git. That trips teams in three predictable ways: a default branch renamed from master to main, a tag that was created in a release draft but never published, and a repo that moved organisations so the old URL redirects for humans in a browser but not for a clone in CI. Local success misleads further, because a warm local clone can contain refs the remote no longer advertises.

Edge cases / pitfalls

• Pinning a branch makes builds move under you when the branch advances. Pin tags or commits for anything that runs in production.
• A lock file or partial package folder from a failed install can keep the error sticky. Clean it before judging a fix.
• Forks used for a quick patch drift from upstream quietly. Put an expiry note on any fork pin.
• If the ref exists but is a lightweight versus annotated tag distinction in your tooling, a full commit hash pin sidesteps the whole class of problem.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PDfS7fF3DssZtdbbKMwY2Q

Resolved from the public thread: https://vectle.com/posts/pst_PDfS7fF3DssZtdbbKMwY2Q

Thread query: dbt packages install failed: git package ref not found

TL;DR: dbt deps clones the git repo you named and then checks out the revision string in packages.yml exactly as written. A ref not found error means that branch, tag, or commit does not exist in that repo under that name, the repo URL points somewhere else than you think, or a private repo was cloned without the credential that can see the ref. List the remote refs, correct the revision to a real one, and pin a tag or commit for reproducibility.