Skip to content

10AM–5PM by appt.
24h urgent appts

📞 0279-088880

All prices include GST

Cart
0 items

Computer Repair Guides

Select the Intended SSH Identity When an Agent Offers Too Many Keys

by AEPC / AKL East PC 28 Sep 2026

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.

Prev Post
Next Post

Thanks for subscribing!

This email has been registered!

Shop the look

Choose Options

Edit Option
Terms & Conditions
Unless otherwise stated, brand new accessories are guaranteed for one year. Second-hand parts are guaranteed for three months. Repair (hardware) is guaranteed for one month. The software is not covered by the warranty, you should contact the software development organization for technical support and after-sales service. The warranty is limited to the same position fault; the customer should provide the warranty with the complete Warranty sticker and the receipt of payment. Otherwise, it will not be guaranteed. (If the warranty label is damaged for any reason, is not covered by warranty.) Returns and refunds Please read our Return & Refund Policy for the current return timeframe, conditions, fees, return methods and refund processing time.
this is just a warning
Login
Shopping Cart
0 items