Select the Intended SSH Identity When an Agent Offers Too Many Keys
A workstation used for several accounts can have several SSH identities available through its agent. An authentication failure may occur before the key intended for one server is successfully used. First confirm the target account and the key that its administrator has authorised; generating another key is not the first diagnostic step.
Keep the private key on the client. The administrator needs the corresponding public key or its fingerprint for an account check, not a copy of the private file or its passphrase.
Inspect the identity selection
OpenSSH's IdentityFile setting selects identity files, while IdentitiesOnly yes limits authentication to configured identities even if an agent offers others. Multiple IdentityFile entries accumulate; adding another entry does not necessarily replace earlier ones.
Inspect the configuration matching this host. For a deliberately scoped test, specify the intended identity and IdentitiesOnly yes for that destination, while accounting for any other matching IdentityFile entries. Avoid changing a global rule used by unrelated customer or work accounts.
Record the original setting before editing. If a managed configuration supplies the identity, ask its owner to review the effective selection rather than deleting the managed entry. A private-key passphrase prompt and the remote account's password prompt are different requests; read their wording before entering anything.
Confirm the right account actually accepts it
Retry once with the agreed identity selection and preserve the result. If diagnostic output is needed, review it privately and share only the relevant key-selection and authentication lines, removing unrelated usernames, hostnames and file paths.
When the selected key is refused, have the administrator verify the public key against the intended remote account and access policy. Restricting what the client offers cannot grant a key that the server has not authorised.
After a successful login, check the account and expected server context before running work commands. Confirm that your other established connections still use their original identities. The useful outcome is a predictable per-account selection, not a broadly weakened authentication policy or an agent emptied of everyone's keys.
Sources: Ubuntu documentation.