The config's fingerprint does not match any API key on your IAM user. Compare `oci iam user api-key list` output with the `fingerprint=` line in `~/.oci/config`; if nothing matches, upload the current public key in the console (or regenerate the pair and upload the new public key). The signature check fails before anything else.

```text
$ oci iam user list
ServiceError:
{
    "code": "NotAuthenticated",
    "message": "The required information to complete authentication was not provided."
}
```

## Fix

1. Show the fingerprint the CLI is sending:
   ```bash
   grep -A1 '^\[DEFAULT\]' ~/.oci/config | grep fingerprint
   ```

2. List the keys the console knows about (use a working profile, the console, or another machine):
   ```bash
   oci iam user api-key list --user-id [user ocid] --profile [working-profile]
   ```
   Expected: fingerprints of uploaded keys.

3. If none match, upload the right public key: console, Identity, Users, your user, API Keys, Add API Key, paste `~/.oci/oci_api_key_public.pem`.
   Expected: the new key's fingerprint equals the config's.

4. If the private key itself is lost, regenerate both halves:
   ```bash
   oci setup keys
   ```
   Then upload the new public key and update the fingerprint line in the config.

## When this applies
- 401/NotAuthenticated with a config file that parses and a profile that exists.
- After `oci setup keys`, copying configs between machines, or key rotation.

## When it does NOT apply
- Session-auth (`oci session authenticate`) expiry: refresh the session.
- `ConfigFileNotFound` / `ProfileNotFound`: earlier-stage problems.

## Compatibility
- oci-cli 3.x API-key auth.

## Why it happens
OCI signs each request with the private key and identifies the key by fingerprint; the service looks up that fingerprint on the user. Regenerating keys, uploading the wrong public half, or editing the fingerprint line by hand all break the lookup, and the service rejects the signature without saying which half is wrong.

## Edge cases
- Multiple keys per user are allowed; the fix is a match, not uniqueness. Delete stale keys to reduce confusion.
- Line-ending damage from Windows editors can corrupt the PEM; regenerate rather than hand-fixing.
- The same mismatch pattern bites `~/.kube/config` exec plugins and Terraform providers sharing the key pair.