Stop Storing SSH Keys in Your CI/CD Secrets. They Are Already Stolen

Long-lived SSH private keys stored in CI/CD variables create persistent security risks because compromised runners, workflow steps, dependencies, or administrators can expose credentials that are difficult to rotate and provide limited attribution. Citing incidents involving CI/CD runners and reports on widespread, long-lasting secret exposure, the piece argues that SSH deployments have not adopted the short-lived OIDC federation model increasingly used for cloud APIs. It proposes keyless, brokered SSH access in which a pipeline authenticates through an identity provider, receives narrowly scoped temporary access for a particular job and target, and leaves no reusable private key on the runner. Twingate Privileged Access for SSH is presented as one implementation, using service accounts, policy-controlled resources, outbound connectors, encrypted tunnels, session logging, and per-session verification to limit exposure and avoid publicly accessible SSH ports. The recommended approach is to inventory existing deployment keys, treat unrotated keys as potentially compromised, migrate a high-risk deployment path to brokered access, then remove stored keys and associated authorized_keys entries.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.