The runner masks secrets per log line, so a multi-line PEM key passed as private_key isn't matched and shows up in plain text in the step's env: block in the log. This leaked the dev deploy key via the matching ssh-upload step in the analytics-server deploy-dev workflow, and this action takes the key the same way.
Change
private_key can now be a single-line base64-encoded key (base64 -w0 <keyfile>), which the runner masks like any other secret. It's decoded into ~/.ssh/ssh_command_key before use.
Values containing -----BEGIN are still written as-is, so existing callers passing a raw PEM key keep working (but remain unmasked).
Updated the input description.
Tested locally with a throwaway ed25519 key: both the raw and base64 forms produce a byte-identical, valid key file.
Rollout
Merge this (and the matching change in ssh-upload) before switching DEV_SSH_PRIVATE_KEY to the base64 value, since the current main would write the base64 string out verbatim.
## Problem
The runner masks secrets per log line, so a multi-line PEM key passed as `private_key` isn't matched and shows up in plain text in the step's `env:` block in the log. This leaked the dev deploy key via the matching `ssh-upload` step in the analytics-server `deploy-dev` workflow, and this action takes the key the same way.
## Change
- `private_key` can now be a single-line base64-encoded key (`base64 -w0 <keyfile>`), which the runner masks like any other secret. It's decoded into `~/.ssh/ssh_command_key` before use.
- Values containing `-----BEGIN` are still written as-is, so existing callers passing a raw PEM key keep working (but remain unmasked).
- Updated the input description.
Tested locally with a throwaway ed25519 key: both the raw and base64 forms produce a byte-identical, valid key file.
## Rollout
Merge this (and the matching change in `ssh-upload`) before switching `DEV_SSH_PRIVATE_KEY` to the base64 value, since the current `main` would write the base64 string out verbatim.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Multi-line secrets aren't masked by the runner, so a raw PEM key passed
as private_key ends up in plain text in the step's env block in the log.
Accept a single-line base64-encoded key instead, which is masked like
any other secret. Raw PEM keys still work for backwards compatibility.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
The runner masks secrets per log line, so a multi-line PEM key passed as
private_keyisn't matched and shows up in plain text in the step'senv:block in the log. This leaked the dev deploy key via the matchingssh-uploadstep in the analytics-serverdeploy-devworkflow, and this action takes the key the same way.Change
private_keycan now be a single-line base64-encoded key (base64 -w0 <keyfile>), which the runner masks like any other secret. It's decoded into~/.ssh/ssh_command_keybefore use.-----BEGINare still written as-is, so existing callers passing a raw PEM key keep working (but remain unmasked).Tested locally with a throwaway ed25519 key: both the raw and base64 forms produce a byte-identical, valid key file.
Rollout
Merge this (and the matching change in
ssh-upload) before switchingDEV_SSH_PRIVATE_KEYto the base64 value, since the currentmainwould write the base64 string out verbatim.🤖 Generated with Claude Code