SSH Key-Based Authentication Testing
Test key-based access cleanly, without your client spamming every identity and tripping server-side auth limits. Most servers enforce MaxAuthTries, and an OpenSSH agent with many loaded keys will burn through that budget before your target key ever gets tried.
Confirm the server will even accept publickey
If publickey isn't offered, stop. Key testing is wasted effort. Run with -vvv and scan the verbose output for a line like debug1: Authentications that can continue: publickey,password. That line tells you exactly which methods the server advertises. If publickey is absent, the server rejects keys entirely regardless of what you throw at it. Check for PubkeyAuthentication no in the server config if you have access to it. Password-only setups are common on older or locked-down infrastructure.
In the verbose output, look for debug1: Authentications that can continue: and confirm publickey appears in the list. If you see debug1: Server accepts key during an actual auth attempt, the public half matched an authorized_keys entry and the private key is valid. If the key is wrong or absent from the authorized list, the connection closes with Permission denied (publickey) before you get a prompt.
Test a known private key
Use the key directly and keep it tight. If the key has a passphrase, the client will prompt for it unless you pre-load it into the agent with ssh-add. For scripted testing across multiple targets or usernames, add BatchMode=yes so the client exits immediately on any interactive prompt instead of hanging indefinitely.
If you want a fast fail without prompts, BatchMode=yes disables all interactive input including passphrase prompts and host key acceptance dialogs. The client exits non-zero on any failure, which makes it suitable for scripting key tests across multiple accounts or hosts.
Permission denied (publickey).
That means the key was offered and rejected. The server received the public half, checked it against ~/.ssh/authorized_keys for that account, and found no match. The key itself is valid, but the username may be wrong, the home directory permissions may block access, or the key simply isn't listed for that account. Try alternate usernames before discarding the key.
Avoid "Too many authentication failures"
If you have many keys loaded, OpenSSH will try several identities. Some servers drop you before it tries the right one. The default MaxAuthTries is 6 on most OpenSSH servers. An ssh-agent with 10 or more loaded keys exhausts that limit before reaching the key you actually intend to test. IdentitiesOnly=yes tells the client to use only the key specified with -i and to ignore everything the agent offers. This keeps the auth attempt count to exactly one.
If you're still getting dropped, run verbose and watch which keys the client offers. Look for debug1: Offering public key: lines followed by the key path and type.
Common reasons a key is rejected even when offered:
The public half is not in
authorized_keysfor that userHome directory or
.ssh/permissions are too openThe server restricts key types via
PubkeyAcceptedKeyTypesOlder servers reject Ed25519, requiring RSA instead
References
-
ssh(1) manual pageLINK: ssh(1) manual page, man.openbsd.org/ssh (opens in new tab)
Identity selection, verbosity, and auth method controls.
-
ssh_config(5) manual pageLINK: ssh_config(5) manual page, man.openbsd.org/ssh_config (opens in new tab)
IdentitiesOnly and related client-side auth behavior.