Addendum 1:
Thank you for the responses so far, which have all been very helpful. Unfortunately, I made a mistake in my thinking. The actual problem occurs when I execute RAILS_ENV=test rails webpacker:install in my pipeline or when yarn install is executed in the course of this. This accesses the package.json. The package.json contains the following line:
"foo-app": "ssh://git@foo.bar.com:7999/pac/foo-app.git".
I thought that if I could clone the repo, this access would also work. But this is not the case and I get the following error message:
Installing all JavaScript dependencies [5.4.4]
run yarn add @rails/webpacker@5.4.4 from "."
yarn add v1.22.19
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
[1/4] Resolving packages...
[2/4] Fetching packages...
error Command failed.
Exit code: 128
Command: git
Arguments: ls-remote --tags --heads ssh://git@foo.bar.com:7999/pac/foo-bar.git
Directory: /workspace
Output:
Repository not found
The requested repository does not exist or you are not authorised to access it.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.
Installing webpack and webpack-cli as direct dependencies
run yarn add webpack@^4.46.0 webpack-cli@^3.3.12 from "."
yarn add v1.22.19
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
[1/4] Resolving packages...
[2/4] Fetching packages...
error Command failed.
Exit code: 128
So my problem is actually that I want to access a bb repo in the course of yarn install and it doesn't work that way.
Original question:
I have a server running Jenkins. The SSH key of the Jenkins server is stored with my Bitbucket repo. I can run the following command from the Jenkins server and clone the contents of the repo to my Jenkins server:
git clone ssh://git@bb.repo-to-connect-to.com:7999/pac/sample-repo.git
And I can SSH from the Jenkins server to another server with the following command:
ssh -i ~/.ssh/id_rsa test_user@testServer.testhost.host
On the Jenkins server, a Docker container is running from which I would also like to access the BB repo. If I copy id_rsa and id_rsa.pub into ~/.ssh of the Docker container and now connect to the container with docker exec -it test_rails_container bin/bash
and execute -i ~/.ssh/id_rsa test_user@testServer.testhost.host, the Docker container connects to the testServer via SSH. However, I cannot run git clone ssh://git@bb.repo-to-connect-to.com:7999/pac/sample-repo.git. When I do, I get the following error:
git clone ssh://git@bb.repo-to-connect-to.com:7999/pac/sample-repo.git
Cloning into 'sample-repo'...
git@bb.repo-to-connect-to.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I have now tried various other possibilities. Among other things, I created a new SSH key, registered it in the BB and tried to clone the repo (without success).
Can anyone tell me where I have made a mistake or whether I have made some kind of error in thinking?
IMHO your straight forward thinking is good, you perhaps have discovered a little gap in the configuration. Let me explain what I mean by that.
When using git+ssh it may obtain additional configuration details from the ~/.ssh/config file (the user configuration file of the SSH client) that it would not in case of in your docker container as it is different there.
When you review the working command, you can see that a configuration option is in action:
$ ssh -i ~/.ssh/id_rsa test_user@testServer.testhost.host
^^^^^^^^^^^^^^^^
It tells the SSH client which key to use. Now when git executes, it won't know about that option and (depends on configuration, so only one example, albeit common) ssh consults its local configuration (e.g. ~/.ssh/config) to see if for the hostname some specific configuration is available. For example the key.
Now if we compare that with the Miscellaneous section¹ in Git Internals - Environment Variables¹ we can find the following description of the GIT_SSH_COMMAND environment parameter which contains something now familiar to us:
GIT_SSH_COMMANDsets the SSH command used when Git tries to connect to an SSH host. The command is interpreted by the shell, and extra command-line arguments can be used withssh, such asGIT_SSH_COMMAND="ssh -i ~/.ssh/my_key" git clone git@example.com:my/repo.
To highlight the specific setting
GIT_SSH_COMMAND="ssh -i ~/.ssh/my_key"
^^^^^^^^^^^^^^^^
we can see that this is exactly the configuration to tell the SSH client where the key file is located.
So speaking of Docker, you could give it a try and have this environment parameter set within the containers environment and then at least Git should use that file for SSH.
TLDR: Tell Git which SSH key to use, otherwise it will try without and then you (rightfully, right?) get access denied.
Extra Commentary: Using the GIT_SSH_COMMAND parameter is only one way to do it. Understand the cause of the issue and which part exactly of the configuration was missing, then provide it. Things then just work.
And a warning upfront: Do not copy the whole ~/.ssh/config file into the container. That is begging for troubles. Both for implementing without understanding as well as it is - unless you precisely know what you are doing - overreaching with very grave potential security implications. This is not the SSH config for the container, it is the one for the host. Be lazy the correct way. Take care.