SSH Permission Denied (publickey) — Find Which Key Was Rejected

Diagnostic flow — target → key → authorization

Fix #2 — verify the target and remote user before touching keys

A public key authorizes an account on a particular SSH service; it does not grant universal access to a host. Check command-line user@host, Git remote URLs, host aliases and effective SSH configuration. Hosted Git services can require a service-specific SSH username—for example, GitHub's SSH endpoint uses git, not your GitHub account name.

ssh -G prints the client's evaluated configuration; it is useful for checking values such as HostName, User, Port and IdentityFile, but it does not prove that a key was successfully loaded, signed with, offered, or accepted at runtime. Keep ssh -v as the runtime source of truth.

Verify: Verbose output connects to the intended host/port and shows the intended remote user before authentication begins.

Fix #3 — prove the intended private key is available

ssh-add -l shows identities currently held by the agent; it does not prove that a particular host connection will offer them. Also check whether the intended private-key file exists if you expect file-based discovery or an IdentityFile rule.

If the expected key is absent, determine whether it already exists under a non-default name, needs to be loaded into the appropriate agent, or should be referenced by host-specific config. Remember that configured IdentityFile entries and agent identities interact: OpenSSH can use agent identities in addition to configured identity files unless IdentitiesOnly restricts the set. Generate a new key only when you have established that the required identity truly does not exist or intentionally needs replacement.

Verify: You can identify the intended key by path or fingerprint without exposing the private key.

Fix #4 — key exists but SSH does not offer it

Test the intended identity explicitly. -i names an identity file; when multiple agent identities or config rules interfere, IdentitiesOnly=yes can restrict authentication to configured/explicit identities for the test.

IdentitiesOnly=yes is a selection control, not a repair by itself: it tells OpenSSH to use configured/explicit identities rather than every identity an agent may offer. If this controlled test works, make the selection host-specific in ~/.ssh/config rather than relying on a long global agent list. If your original error is instead Too many authentication failures, use the sibling guide because the server may disconnect before the intended identity is reached.

Verify: verbose output now contains the intended identity/fingerprint. Continue reading: determine whether the server rejects the candidate, accepts it but the client/agent cannot sign, rejects the signed authentication, requires another authentication method, or reaches Authenticated to.

Fix #5 — correct key is offered but the server rejects it

Once the intended key is demonstrably selected/offered, stop changing client key discovery unless the verbose transition shows a client signing problem. Verify that the matching public key is authorized for the same remote user and connection context. On a server you administer, inspect the account's effective sshd configuration—not only the first global line or an unqualified config dump. Match rules can depend on criteria such as user, source address/host and local address/port. Where supported, use sshd -T with the appropriate -C connection parameters to evaluate the context that actually failed. AuthorizedKeysFile, AuthorizedKeysCommand, PubkeyAuthentication, AuthenticationMethods and StrictModes can all alter acceptance. Check ownership/modes only against that effective policy and actual authorized-key source.

Do not loosen permissions broadly with chmod 777, disable StrictModes as a first fix, or replace authorized_keys wholesale. Preserve another working administrative session while changing remote access.

For managed Git/SSH services, compare the offered key's fingerprint with the key registered to the intended account/organization and consider service-side access policy. You may not have filesystem access to authorized_keys at all.

Verify: Retry the exact connection and confirm the server accepts the intended key for the intended account—without weakening authentication policy.

Fix #6 — key is offered, but signing or algorithm/policy fails

Do not collapse every post-offer transition into “wrong authorized_keys.” In the SSH public-key protocol, identifying/offering a key and completing a signed authentication request are distinct evidence points. Verbose output may show that the server is willing to consider a key but the agent cannot sign, that the client/server refuses a key or signature algorithm, that the signed request is rejected, or that public key is only the first step of an AuthenticationMethods chain. Preserve the exact transition and diagnose that branch rather than generating another key blindly.

For old RSA deployments in particular, distinguish the key from the signature algorithm negotiated for authentication. Avoid globally re-enabling legacy algorithms as a first response; prefer a supported server/client upgrade or the narrowest host-specific compatibility change when one is truly required.

Verify: The intended key can sign successfully, the negotiated authentication policy permits it, and verbose output progresses past the previously failing policy/signing step.

Fix #7 — the key is accepted: stop troubleshooting public-key authentication

If verbose output shows successful authentication, a later git push, shell, command, or SFTP failure is a different layer. Repository permissions, forced commands, shell restrictions and SFTP subsystem startup can all fail after identity authentication succeeds.

Verify: Run the exact connection/test expected by the service and separate authentication success from the next failing operation.

Still seeing Permission denied (publickey)?

Capture the authentication transition rather than the entire noisy log. The key question is where the chain first diverges: target, user, availability, offer, rejection or authorization.

Official references