The runner masks secrets per log line, so a multi-line PEM key passed as ssh-key can show up in plain text in the step's env: block in the log (this happened with the deploy key in ssh-upload). ssh-upload and ssh-command now accept a base64-encoded key, but this action still wrote the secret out as-is. A base64 GIT_SSH_KEY therefore ends up as an unparseable key file:
Load key "/root/.ssh/gitea_key": error in libcrypto
git@git.mmquack.nl: Permission denied (publickey).
(analytics-server run 1632, job 4219)
Change
ssh-key can now be a single-line base64-encoded key (base64 -w0 <keyfile>), which is decoded into ~/.ssh/gitea_key.
Values containing -----BEGIN are still written as-is, so existing callers passing a raw PEM key keep working (but remain unmasked).
## Problem
The runner masks secrets per log line, so a multi-line PEM key passed as `ssh-key` can show up in plain text in the step's `env:` block in the log (this happened with the deploy key in `ssh-upload`). `ssh-upload` and `ssh-command` now accept a base64-encoded key, but this action still wrote the secret out as-is. A base64 `GIT_SSH_KEY` therefore ends up as an unparseable key file:
```
Load key "/root/.ssh/gitea_key": error in libcrypto
git@git.mmquack.nl: Permission denied (publickey).
```
(analytics-server run 1632, job 4219)
## Change
- `ssh-key` can now be a single-line base64-encoded key (`base64 -w0 <keyfile>`), which is decoded into `~/.ssh/gitea_key`.
- 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.
Same logic as megamiley/ssh-upload#2 and megamiley/ssh-command#1.
🤖 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 ssh-key can end 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
ssh-keycan show up in plain text in the step'senv:block in the log (this happened with the deploy key inssh-upload).ssh-uploadandssh-commandnow accept a base64-encoded key, but this action still wrote the secret out as-is. A base64GIT_SSH_KEYtherefore ends up as an unparseable key file:(analytics-server run 1632, job 4219)
Change
ssh-keycan now be a single-line base64-encoded key (base64 -w0 <keyfile>), which is decoded into~/.ssh/gitea_key.-----BEGINare still written as-is, so existing callers passing a raw PEM key keep working (but remain unmasked).Same logic as megamiley/ssh-upload#2 and megamiley/ssh-command#1.
🤖 Generated with Claude Code