Re-running jobs with SSH restricts SSH sessions to the GitHub user that initiated the job re-run

Build Environment
,
1

This is another way to unexpectedly leak secrets for public projects.

From my perspective, the simplest thing would be to have SSH sessions require an SSH key. Only authorized SSH keys will be allowed SSH access. In the short-term, can we have an option to disable Re-run job with SSH?

Works as expected, see my last comment.

2

What secrets do you have in mind? Are these per-org secrets set up via a context?

I wonder if secrets should be stored per-user, so that if an anonymous contributor requests an SSH session, their account won’t have set up the required secrets anyway.

3

This is a big feature request for us, as we would love to deploy our applications using CircleCI, but we have access control issues since our builds require code signatures with certificates we do not want to expose to the entire dev team.

4

These are regular per-org secrets, set via envvar API endpoint.

Regardless how this gets addressed, it’s important that secrets do not get exposed via anonymous SSH sessions, which is what happens when a build is re-run using SSH.

1 Like
5

I share the git-ops mindset, as illustrated by Weave Flux.

For changelog.com, there is an update service in the Docker Stack that continuously updates the app:

This approach keeps production secrets in production, as captured in this changelog.com Docker Stack.

As soon as the 2019 changelog.com infrastructure goes live, I will blog & talk about it, stay tuned ; )

6

I have looked at this with a fresh pair of eyes and can confirm that this is not an issue, SSH access is restricted to the SSH keys that I have stored in GitHub, e.g. https://github.com/gerhard.keys:

You can now SSH into this box if your SSH public key is added:
    $ ssh -p 64537 34.229.201.165

Use the same SSH public key that you use for your VCS-provider (e.g., GitHub).

RSA key fingerprint of the host is
  SHA256:vtBxs9klpcNvhnj8+wxjapGxzVhiMsXwcF6uRUN4XCU
  MD5:4c:29:d5:aa:b9:19:55:0b:36:28:91:c4:01:c1:b9:d5

SSH Session Activity Log (times in UTC):
Jan 17 09:29:07 Authorizing gerhard with MD5:0a:cc:dd:82:23:46:98:a4:2b:69:3c:9d:45:c2:c8:aa
Jan 17 09:29:07 Authorizing gerhard with MD5:e5:0a:b6:18:5f:45:6c:50:57:28:cc:26:94:96:c6:9d
Jan 17 09:29:07 Authorizing gerhard with MD5:ce:be:71:c9:32:27:32:cf:c6:d1:6c:11:46:42:b8:9a

I confirmed by trying to SSH from a host where I do not have access to my SSH keys:

ssh-add -l
Could not open a connection to your authentication agent.

ssh -p 64537 34.229.201.165
The authenticity of host '[34.229.201.165]:64537 ([34.229.201.165]:64537)' can't be established.
RSA key fingerprint is SHA256:vtBxs9klpcNvhnj8+wxjapGxzVhiMsXwcF6uRUN4XCU.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[34.229.201.165]:64537' (RSA) to the list of known hosts.
root@34.229.201.165: Permission denied (publickey).
1 Like
7

It might not be an issue if all devs who have Github write access to the project can see the deploy keys, but in our case, we specifically do not want most of the dev team to have any way of accessing the prod credentials via SSH that would be on the machine.

Unless I’m totally thinking about this wrong.

1 Like
8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.