## 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.

```text
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