dbt-snowflake: private key authentication failed

Not specified by the original author.

TL;DR

The key dbt presents is not what Snowflake expects: wrong format, wrong passphrase, or the public half was never assigned to the user. Verify the key loads locally, check the passphrase handling, and confirm the RSA public key is set on the Snowflake user.

Error

dbt-snowflake: private key authentication failed

Steps

1. Check the key file the profile points at exists and is PEM format: the file should start with a BEGIN PRIVATE KEY or BEGIN RSA PRIVATE KEY header. Expected: You confirm the file exists and is a real PEM key, not a public key or a truncated file.

2. If the key is encrypted, confirm profiles.yml passes the passphrase correctly (privatekeypassphrase) and that the passphrase is right by decrypting once locally with openssl. Expected: openssl decrypts the key with the passphrase, proving both are good.

3. In Snowflake, check the user has the public key assigned: describe user theuser should show RSAPUBLIC_KEY set, and it must match your private key's public half. Expected: The public key on the user matches your key pair.

4. Run dbt debug to test the connection. Expected: Connection test passes with key-pair auth.

When to use

• dbt-snowflake fails with private key authentication failed
• rotating Snowflake keys for the dbt service user
• moving from password auth to key-pair auth

When not to use

• password authentication failed (different auth method, check the password)
• connection timeouts (network, not auth)
• the key works locally but dbt Cloud fails (check the Cloud credential setup instead)

Tool compatibility

• dbt-snowflake adapter; privatekeypath and privatekeypassphrase profile fields
• openssl to validate the key and passphrase offline
• Snowflake describe user to verify the assigned public key

Variant phrasings

private key auth failed after key rotation

The new public key was never assigned to the user, or dbt still points at the old private key file. Update both sides together.

key file not found error instead

The path in profiles.yml is wrong or relative to a different working directory. Use an absolute path.

Why it happens

Key-pair auth has three moving parts: the private key file dbt reads, the passphrase that unlocks it, and the public key registered on the Snowflake user. Any one of them being wrong or stale produces the same generic failure, so you verify each link in the chain.

Edge cases

• Snowflake accepts only unencrypted or correctly-passphrased keys; a passphrase with YAML special characters needs quoting in profiles.yml.
• Keep private keys out of git; reference a path outside the repo or a secrets manager.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CDxXAEOtQQwb-PzqlpWiCQ

Resolved from the public thread: https://vectle.com/posts/pst_CDxXAEOtQQwb-PzqlpWiCQ

Thread query: dbt-snowflake: private key authentication failed

TL;DR: The key dbt presents is not what Snowflake expects: wrong format, wrong passphrase, or the public half was never assigned to the user. Verify the key loads locally, check the passphrase handling, and confirm the RSA public key is set on the Snowflake user.

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.

dbt: 250001 Failed to connect to DB: Incorrect username or password was specified

TL;DR: Snowflake rejected the username/password in your profile. First rule out typos in profiles.yml (trailing spaces are a classic), then check whether the password expired or the account uses SSO or key-pair auth instead of a password. If your org requires SSO, set authenticator: externalbrowser; if it requires key pairs, switch to private_key auth.

250001 (08001): Failed to connect to DB: [account].snowflakecomputing.com:443. Incorrect username or password was specified.

Steps

1. Open profiles.yml and re-read the user and password lines character by character; strip trailing spaces. Rerun dbt debug. Expected: either it connects or the error persists with clean input.
2. Log into Snowflake in a browser with the same username and password. If that fails too, the password is wrong or expired: reset it (or ask your admin to) and update profiles.yml.
3. If browser login works but uses SSO, your profile must not use password auth. Set authenticator: externalbrowser in the profile and rerun; a browser window opens for the SSO flow.
4. If your org uses key-pair auth, replace the password with the private_key settings in the profile. Expected: dbt debug shows Connection test: OK.

When this applies

• the exact Incorrect username or password was specified (250001) error from dbt debug or dbt run against Snowflake
• CI pipelines where the Snowflake password rotated but profiles.yml still has the old one
• orgs that moved to SSO while profiles still say password

When it doesn't

• Incorrect role or warehouse-not-found errors — those mean auth succeeded and object access failed
• network/timeout errors reaching the Snowflake host
• expired private keys (different error: JWT / key mismatch)

Compatibility

dbt Core and Fusion CLIs with the dbt-snowflake adapter; password, externalbrowser (SSO), and key-pair authenticators. Verified against the dbt-action issue thread.

Variant phrasings

• dbt snowflake incorrect username or password was specified
• dbt 250001 failed to connect to db
• dbt snowflake password expired fix

Root cause

Error 250001 comes from Snowflake's login endpoint, not from dbt: the credential bundle (user + password, or the authenticator choice) did not match what Snowflake expects for that user. dbt just surfaces it.

Edge cases

• passwords with special characters are fine in YAML but must be quoted if they start with special chars
• SSO with externalbrowser does not work in headless CI; use key-pair auth there
• a locked-out Snowflake user gives a different error; unlock via the admin console

dbt surfaces Snowflake error 250001 when the credentials in profiles.yml are rejected: wrong password, expired password, or the wrong authenticator (password used where the account requires SSO or key-pair). The verified fix from the dbt-action issue thread: verify the password in the Snowflake UI, switch the profile to externalbrowser for SSO or to private_key auth for key pairs, and rerun dbt debug. Source: https://github.com/mwhitaker/dbt-action/issues/44