Permission denied (publickey) in automation ssh: key debugging

Not specified by the original author.

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.

Not specified by the original author.

TL;DR

Specify the key file explicitly on the connect command: ssh -i ~/.ssh/lambda_key.pem ubuntu@[instance IP].

The error

Permission denied (publickey) when connecting to a Lambda GPU Cloud instance

Fix

1. Specify the key file explicitly on the connect command: ssh -i ~/.ssh/lambda_key.pem ubuntu@[instance IP]. Expected: you can confirm this matches your situation.

2. Re-run the original operation and confirm the error is gone. Expected: no error, normal output.

When to use

• You hit this exact error.
• The symptom matches: Permission denied (publickey) when connecting to a Lambda GPU Cloud instance.

When NOT to use

• A different error message; the cause here is specific to this error.
• Unrelated issues with a different cause.
• You need general documentation for the tool; check the official docs instead.

Compatibility

Reported per the linked source. Source: https://github.com/piperandrew/textmining_py/blob/HEAD/usingLambdaAI.MD.

Variant phrasings

Permission denied (publickey) when connecting to a Lambda GPU Cloud instance

Why it happens

SSH to a Lambda (lambda.ai) GPU Cloud instance fails with Permission denied (publickey) right after launch, even though an SSH key was added when the instance was created. The default login user on Lambda instances is ubuntu, and the ssh client often picks the wrong local key.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Source

https://github.com/piperandrew/textmining_py/blob/HEAD/usingLambdaAI.MD

Source: SSH to a Lambda (lambda.ai) GPU Cloud instance fails with Permission denied (publickey) right after launch, even though an SSH key was added when the instance was created. The default login user on Lambda instances is ubuntu, and the ssh client often picks the wrong local key.

Verified resolution: [troubleshooting notes]: Specify the key file explicitly on the connect command: ssh -i ~/.ssh/lambda_key.pem ubuntu@[instance IP]. If it still fails, confirm the key you passed at instance launch matches the local private key (the public half must be on the instance). Permission denied (publickey) on Lambda almost always means the wrong local key, not a server-side problem.

Source URL: https://github.com/piperandrew/textmining_py/blob/HEAD/usingLambdaAI.MD

Not specified by the original author.

TL;DR

"Host key verification failed" means the target's SSH host key is not in the automation user's knownhosts, and non-interactive ansible cannot answer the prompt. The right fix is to pre-populate knownhosts with the hosts' keys (fetched once and committed or distributed securely) and point ansible at that file. Do not disable host key checking globally to make the error go away - that trades a five-minute fix for a standing MITM hole.

ansible "Host key verification failed" in automation: how to fix

Steps

1. Confirm the failure is host-key verification and not authentication: the error names the host key, not a password or key problem. Expected: the message is exactly "Host key verification failed", so you know it is the known_hosts lookup.

2. Fetch the target host's public host keys once from a trusted network. Expected: you have the host's key lines ready to install; verify the fingerprint against your inventory or console if this is the first contact.

3. Install those keys into the knownhosts file of the user that runs ansible (often a CI service account, not your login). Expected: the automation user's knownhosts contains the target host entries.

4. Point ansible at that known_hosts file via its SSH arguments or inventory config, and re-run the playbook. Expected: the SSH handshake verifies the host key silently and the playbook proceeds past the connection step.

5. For fleets, distribute a managed known_hosts file with your provisioning or store per-host keys in inventory instead of fetching at runtime. Expected: new hosts work on first run with no manual key acceptance anywhere.

Use this when

• ansible fails with "Host key verification failed" on fresh or rebuilt hosts
• playbooks run from CI runners or service accounts with empty known_hosts
• host keys rotated after a rebuild and old entries no longer match

Not for this skill when

• SSH fails with permission denied or authentication errors - that is keys or passwords, not host verification
• the host is unreachable - fix the network first
• privilege escalation fails on the target - that is become/sudo config, unrelated to host keys

Variant phrasings

• ansible ssh host key verification failed
• ansible known_hosts automation
• StrictHostKeyChecking ansible playbook
• ansible add host key automatically

Why it happens

OpenSSH refuses to connect to a host whose key it has never seen, and interactively asks to accept it. Automation has no terminal to answer, so the connection dies with this error. CI runners and containers start with empty known_hosts, which is why playbooks that work from a laptop fail in the pipeline.

Edge cases

• After a host rebuild the key changes and the old entry mismatches - remove the stale entry rather than bypassing the check
• Hashed known_hosts entries are harder to audit; keep a plaintext managed copy for fleets
• Disabling host key checking in group vars to "fix" this silently removes MITM protection for every host - scope any exception to a single throwaway lab host if you must
• ssh-keyscan output should be verified against a trusted fingerprint on first contact, or you are just automating trust-on-first-use

Provenance

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

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

Thread query: ansible "Host key verification failed" in automation: how to fix

TL;DR: "Host key verification failed" means the target's SSH host key is not in the automation user's knownhosts, and non-interactive ansible cannot answer the prompt. The right fix is to pre-populate knownhosts with the hosts' keys (fetched once and committed or distributed securely) and point ansible at that file. Do not disable host key checking globally to make the error go away - that trades a five-minute fix for a standing MITM hole.