Jenkins GitHub App authentication failed remote Repository not found fatal Auth

Not specified by the original author.

TL;DR

Pick by who is acting: - Software acting on its own (a bot, an integration, an agent fleet): a GitHub App, installed on the repos it needs, with fine-grained permissions. - A user signing into your app through GitHub: an OAuth app. - Personal automation for one human: a fine-grained personal access token.

Steps

1. GitHub's docs are explicit that GitHub Apps are preferred over OAuth apps. Pick by who is acting:

• Software acting on its own (a bot, an integration, an agent fleet): a GitHub App, installed on the repos it needs, with fine-grained permissions.
• A user signing into your app through GitHub: an OAuth app.
• Personal automation for one human: a fine-grained personal access token.

2. An App gets short-lived installation tokens scoped to exactly the repositories it is installed on, with only the permissions it requested. There is no long-lived user credential to steal, and uninstalling revokes everything at once. An OAuth app or personal token inherits the user's access, which is almost always broader than the integration needs, and it lives until someone revokes it.
3. - If an integration currently runs on a personal access token belonging to an employee, migrate it to a GitHub App. When that employee leaves, the token story gets ugly.

• Review installed Apps and their permissions the way you review team membership. Unused installs get removed.

When to use

You are seeing this: GitHub's docs are explicit that GitHub Apps are preferred over OAuth apps. Use this skill when you run into "GitHub Apps over OAuth apps and PATs for integrations".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

An App gets short-lived installation tokens scoped to exactly the repositories it is installed on, with only the permissions it requested.

GitHub's docs state that GitHub Apps are preferred over OAuth apps, with both using OAuth-style authorization but Apps offering fine-grained permissions. Source: https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/deciding-when-to-build-a-github-app

Not specified by the original author.

Kustomize shells out to git for remote bases, and git has no valid credential for that host - an expired token, a password where GitHub now demands a token, or a credential helper (like Argo CD CodeConnections) sending the wrong credential to the URL. Make the private base fetch work with plain git first (token with repo read scope), then kustomize build succeeds. For public bases hit by a misbehaving helper, vendor the base instead.

The error

fatal: Authentication failed for 'https://github.com/[org]/[repo]/'
remote: Invalid username or token. Password authentication is not supported for Git operations.

What to do

1. Reproduce with plain git:

git ls-remote https://github.com/[org]/[repo].git HEAD

Expected: Same auth failure outside kustomize.

2. Fix the credential: use a personal access token (classic) or fine-grained token with contents read, as the password; check git credential helpers for stale entries. Expected: git ls-remote succeeds.

3. Rebuild:

kustomize build [dir]

Expected: Remote base fetches and builds.

4. If a platform credential helper poisons public URLs, vendor the remote base into the repo and reference it locally. Expected: No network fetch at build time.

When this applies

• fatal: Authentication failed on kustomize remote bases
• private GitHub bases
• credential helpers sending wrong credentials to public URLs

When it does NOT apply

• repository not found (wrong URL, not auth)
• load-restrictor errors on local files

Works with

kustomize 4.x/5.x with git remote bases

remote: Repository not found. fatal: ... could not read from remote repository

Same fetch path, but the repo does not exist or the token can not see it. Check the URL and token scope.

Why it happens

Remote bases are just git clones under the hood. Kustomize inherits your git credential setup wholesale - when git can not authenticate, the build can not either.

Edge cases

• SSH-based remote bases ([contact email]:...) need an SSH key with a working agent, not an HTTPS token.
• Pin remote bases with ?ref=[sha] so a working build does not drift when the upstream moves.

Resolved from

dev.to kustomize remote bases guide - https://dev.to/jajera/why-your-kustomize-remote-bases-break-on-managed-argo-cd-and-how-to-fix-it-26i6

Asked: kustomize build fails with fatal: Authentication failed fetching a remote base. Verified answer: Fix git auth for the host (token with repo read); vendor the base if a helper poisons the URL. Source: https://dev.to/jajera/why-your-kustomize-remote-bases-break-on-managed-argo-cd-and-how-to-fix-it-26i6 (thread dev.to kustomize remote bases guide). Tool: kustomize.

Not specified by the original author.

The source-controller can not authenticate with the secretRef secret value the secret is missing, the token expired, or the keys are wrong (username/password for HTTPS, identity/known_hosts for SSH). Inspect the GitRepository's secretRef, verify the secret exists with exactly those keys, fix or recreate it, and flux reconcile source git [name] to retry.

The error

GitRepository [name] FetchFailed: authentication error - check secretRef

What to do

1. Find the referenced secret value ```bash

kubectl -n flux-system get gitrepository [name] -o jsonpath='{.spec.secretRef.name}{"\n"}'

   Expected: Prints the secret name.
2. Check it exists with the right keys:
```bash
kubectl -n flux-system get secret [secret] -o jsonpath='{.data}'

Expected: HTTPS needs username+password; SSH needs identity+known_hosts.

3. Fix the secret (recreate with flux create secret git, or fix the keys/format). Expected: Secret valid.

4. Retry:

flux reconcile source git [name] -n flux-system

Expected: FetchFailed clears; Ready=True.

When this applies

• GitRepository FetchFailed with authentication error
• rotated tokens that were never updated in the secret
• SSH secrets with malformed identity keys

When it does NOT apply

• repository not found (URL wrong)
• branch/tag not found (ref wrong)

Works with

flux CLI 2.x; source-controller

HelmRepository auth failures

Same secretRef shape for chart repos. Same key-check fix.

Why it happens

The controller authenticates on every fetch with the current secret contents - there is no caching of a working credential. Rotation or a malformed key breaks the next fetch, and everything downstream stalls on the last good revision.

Edge cases

• An SSH identity key in the wrong format (e.g. PuTTY) fails the same way - use OpenSSH format.
• Self-signed git servers need the caFile key in the same secret or TLS fails first.

Resolved from

gh:fluxcd/agent-skills (gitops-cluster-debug) - https://github.com/fluxcd/agent-skills/blob/HEAD/skills/gitops-cluster-debug/references/troubleshooting.md

Asked: Flux GitRepository reports FetchFailed authentication error after a token rotation. Verified answer: Verify the secretRef secret has the exact keys the URL scheme needs; reconcile to retry. Source: https://github.com/fluxcd/agent-skills/blob/HEAD/skills/gitops-cluster-debug/references/troubleshooting.md (thread gh:fluxcd/agent-skills (gitops-cluster-debug)). Tool: flux-cli.