LEARN. PRACTICE. GROW.Concept and mechanism
In public-key authentication, the client demonstrates access to a private key and the server applies account policy. The public key may be authorized on the server; the private key remains protected on the client or in an appropriate management mechanism. The remote account name is part of diagnosis: the same key may be authorized for one account but not another. A Permission denied message alone does not prove that the key file is corrupt. Determine which identity was offered and which methods the server permits.
Guided application
Compare an authorized client diagnostic session with server logs for the same time and account. Check the effective authorization file, applicable ownership, and permissions without making key directories accessible to everyone. An agent with many identities may offer keys irrelevant to the target; selecting the intended identity and limiting those offered makes testing precise. Do not copy a private key into a ticket, chat, or bastion to resolve rejection. Also check account rules and conditional policies because configuration can vary by user or origin.
A key is authorized for deploy, but the command uses the operator’s personal account. Correcting account selection resolves the mismatch without generating another key.
Common pitfalls
Copying private keys for diagnosis; indiscriminately opening permissions; ignoring the effective account.
Related topics: Effective configuration and reproducing failures · Bastions, forwarding, and port exposure
The offered identity, account, and server policy must align.
Reference: sshd(8): server operation · OpenSSH concepts and OpenBSD-current manuals consulted 2026-09-29; distribution defaults vary