`ssh -vvv` Is the Flag You Should Use When SSH Keeps Failing and the Error Message Is Too Polite to Help

Why this flag matters: SSH errors are often just informative enough to confirm you have a problem and too vague to explain which problem it is.

When SSH fails, the lazy move is to try again with more hope. The useful move is to make the client explain what it is doing. That is what -vvv gives you.

The command

ssh -vvv [email protected]

This enables very verbose client-side debugging output. It is not pretty, but it is incredibly useful when you need to answer questions like:

1. which SSH config block matched this host
2. which identity files were considered
3. which keys were actually offered
4. which auth methods the server accepted or rejected
5. where the connection failed

That is a lot more actionable than staring at:

Permission denied (publickey).

What problems it often uncovers

ssh -vvv is especially good at exposing these client-side mistakes:

1. the wrong private key file is being chosen
2. your host alias does not match the config stanza you thought it did
3. the SSH agent is offering too many identities
4. the username is wrong
5. your config options are being overridden elsewhere

Those are common, and they are easy to miss without verbose output because the default client message hides the decision path.

Example workflow

Suppose this fails:

ssh my-prod-box

Retry with:

ssh -vvv my-prod-box

Now look for clues such as:

1. Reading configuration data ...
2. Applying options for ...
3. Offering public key: ...
4. Authentications that can continue: ...

Those lines tell you what the client believed, which is often the missing piece.

How to turn the output into a fix

If you discover the wrong key is being used, make it explicit:

ssh -i ~/.ssh/my_key [email protected]

Or fix your SSH config:

Host my-prod-box
  HostName example.com
  User deploy
  IdentityFile ~/.ssh/my_key
  IdentitiesOnly yes

If the client is offering too many keys and the server rejects you before the correct one appears, IdentitiesOnly yes is often part of the fix.

What not to do

Do not paste verbose SSH logs publicly without checking them. They can reveal usernames, hostnames, key paths, and other details you may not want floating around.

Also do not assume every SSH problem is on the server. Plenty of them are local-client problems, and ssh -vvv is exactly how you prove that.

Final recommendation

When SSH fails and the default error message feels too bland to help, run ssh -vvv before changing random keys or rewriting config from memory. The verbose trace is often the fastest path from vague failure to a concrete fix.

Sources

• OpenSSH manual