Often the best way to troubleshoot problems is to SSH into a job and inspect things like log files, running processes, and directory paths.
CircleCI allows you to "Rerun job with SSH" which kicks off a new run of the job but will add an extra "Enable SSH" step which will output a command you can run locally to SSH into the build:
You can now SSH into this box if your SSH public key is added: $ ssh -p 12345 1.23.456.789 Use the same SSH public key that you use for your VCS-provider (e.g., GitHub).
However this command is isolated to the user that initiated the "Rerun job with SSH" option. To clarify further, let's take the following example:
Let's say Alex pushes to GitHub, triggering a build. Then Billy -- (who's part of the same team, but logged into his own, separate account) -- clicks the "Rerun job with SSH."
Who is able to SSH into the build — just Alex, just Billy, or both?
In this scenario, as long as Billy has an SSH key set up in GitHub, Billy would be able to SSH in.
However, Alex would not be able to via the SSH info that was generated for Billy (i.e. the example code above). But, if Alex also wanted to SSH in, Alex can go and click the "Rerun with SSH" and get access as long as Alex has an SSH key set up on their GitHub account.
As some added clarification, how about:
Can Connor, who wasn't involved but is also a team member, SSH into the build?
Similar to the above, Connor wouldn't be able to SSH in with the SSH login generated by Billy or Alex, but as long as Connor was a contributor they could "Rerun with SSH" to get their own SSH login link.
In summary, as long as the user has access to the project, and has an SSH key set up on their GitHub account, when that user clicks the "Rerun with SSH" option they will be able to SSH in.
However, the SSH info that is generated will only work for that user.