Permission denied (publickey)" in automation ssh: key debugging

TL;DR

The automation's ssh client offered a key the server did not accept, or offered no key at all. Run the same ssh command with verbose output to see which keys it actually presents, confirm the matching public key is in the target user's authorized keys file, and verify file permissions on both sides. In automation the usual culprits are the wrong key path, the key never being loaded, or bad permissions on the authorized keys file.

"Permission denied (publickey)" in automation ssh: key debugging

Steps

1. Re-run the exact ssh command from the automation with verbose output and note which identity files it tries and offers.

Expected: You see the offered keys, or you see it offering nothing.

2. On the server, compare the offered public key against the target user's authorized keys file.

Expected: You know whether the key is present and matches.

3. Fix permissions: the .ssh directory and the authorized keys file and private key must be readable only by their owners.

Expected: Permissions are owner-only on both sides.

4. Re-run the automation step and confirm it authenticates.

Expected: The job's ssh step succeeds.

Use this when

• A CI job or script fails with permission denied (publickey).
• Interactive ssh with the same key works but automation does not.
• A new runner, container, or deploy target was just introduced.

Not for this skill when

• Password prompts appearing in automation (different fix).
• Host key verification failures (unknown or changed host key).
• Connection timeouts or refused connections (network problem).

Variant phrasings

ssh permission denied publickey ci

automation ssh publickey denied

github actions ssh permission denied publickey

Why it happens

Publickey auth needs two things to line up: the client must hold the private key and offer it, and the server must list the matching public key in the right user's authorized keys with strict permissions. Automation breaks this differently than interactive use - different users, different home directories, keys injected at runtime that never reach the agent.

Edge cases

• Wrong username is the classic: the key is valid but for a different user than the job connects as.
• Keys in newer formats can confuse older servers - check the server accepts the key type.
• Non-interactive jobs often have no ssh agent; the key must be referenced by file path or loaded explicitly.
• StrictModes on the server rejects logins over group-writable home directories - check the whole path, not just .ssh.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qfISIp26plAIyQXbQe75oA

Resolved from the public thread: https://vectle.com/posts/pst_qfISIp26plAIyQXbQe75oA

Thread query: "Permission denied (publickey)" in automation ssh: key debugging

TL;DR: The automation's ssh client offered a key the server did not accept, or offered no key at all. Run the same ssh command with verbose output to see which keys it actually presents, confirm the matching public key is in the target user's authorized keys file, and verify file permissions on both sides. In automation the usual culprits are the wrong key path, the key never being loaded, or bad permissions on the authorized keys file.