A user reports `Permission denied (publickey)` connecting to a Linux server. Walk through what `ssh -vvv deploy@server` tells you about where the failure lies — and what that output fundamentally cannot tell you.

## Why a structured read of `-vvv` beats scrolling it Verbose output is long and most of it is protocol noise. The value comes from knowing the four or five lines that carry a verdict, and what each one lets you eliminate. ## The lines that matter **Which methods are on the table.** ``` debug1: Authentications that can continue: publickey,keyboard-interactive ``` The server sent this list. If `password` is absent, no amount of typing a password will help — that is a server-side decision, and it reframes the whole problem. This line reappears after each failed attempt, and watching the list shrink shows what has already been consumed. **Which identities the client will try.** ``` debug1: Will attempt key: /home/alice/.ssh/id_ed25519 ED25519 SHA256:abc... agent debug1: Offering public key: /home/alice/.ssh/id_ed25519 ED25519 SHA256:abc... ``` `Will attempt` is the candidate list, drawn from the agent and the default identity files. `Offering` means the key was actually presented to the server. The distinction matters: a key can be in the candidate list and never offered because the attempt limit was reached first. **Whether the server liked it.** ``` debug1: Server accepts key: /home/alice/.ssh/id_ed25519 ED25519 SHA256:abc... ``` This is the good line. It means the server found that public key in the account's authorised list. If it is missing and the next thing you see is another `Offering` or the final refusal, the server declined that key. **The end.** ``` deploy@server: Permission denied (publickey). ``` ## The two branches Everything above resolves into one binary split, and stating it cleanly is the point of the question: 1. **Your key was never offered.** The failure is client-side. Causes: the identity you expected is not loaded and not at a default path; the agent is offering five other keys and the server cut the attempt off after the maximum number of tries; the private key file has permissions the client refuses to use, in which case there is a loud `UNPROTECTED PRIVATE KEY FILE` warning above; or you are connecting as a different user than you think. Retrying with a single explicit identity is the fastest way to isolate this — if naming the key makes it work, an over-full agent was the cause. 2. **Your key was offered and the server moved on.** The failure is server-side, and the client will never learn why. Candidate causes, roughly in order of frequency: the key is not in that account's `~/.ssh/authorized_keys`; the ownership or permissions on the home directory, `~/.ssh`, or the file are rejected; on an SELinux host the directory carries a label the daemon may not read; the account is locked or has a `nologin` shell; the account is outside whatever access list the server enforces. ## Why the client is kept in the dark The silence is deliberate. Distinguishing "no such user", "user exists but key not authorised" and "key authorised but modes rejected" to an unauthenticated caller would leak account existence and configuration to anyone who can reach the port. So the client always gets the same terse refusal, and the detail is written on the server. That is the sentence to say out loud in an interview — it explains why so many people go in circles on the client side. ## Finishing the diagnosis on the server ``` journalctl -u sshd -f ``` then reproduce the login. The daemon logs the account, the source address and, on an acceptance, the key type and `SHA256:` fingerprint — which is how you confirm *which* key was used when several are authorised. Refusals are explicit about the modes case (`Authentication refused: bad ownership or modes for directory ...`) and about invalid users. If you need still more, raising the daemon's log verbosity temporarily produces per-attempt detail; put it back afterwards, because the higher levels are noisy and can record more than you want to keep. A useful trick for the ambiguous middle: compare fingerprints across the two sides. `ssh-keygen -lf` over the client's public key and over the lines in the remote `authorized_keys` will tell you in one step whether the key the client offered is even present on the server — which resolves the most common cause without reading a single log line. ## The connection-level cases this does *not* cover If `-vvv` never reaches the authentication stage — it stalls at `Connecting to ...` or the connection is refused or times out — you are not debugging authentication at all; you are debugging reachability, and the answer lies with the network path and whether the daemon is listening, not with keys.