一个跨平台的解决方案是使用绑定挂载将主机的.ssh文件夹共享给容器:

docker run -v /home/<host user>/.ssh:/home/<docker user>/.ssh <image>

与代理转发类似，这种方法将使容器可以访问公钥。另外一个好处是，它也适用于非根用户，并将使您连接到GitHub。但是，需要注意的一点是，.ssh文件夹中的所有内容(包括私钥)都将被共享，因此这种方法只适用于开发，而且只适用于受信任的容器映像。

我把一个非常简单的解决方案放在一起，它适用于我的用例，我使用一个“builder”docker映像来构建一个单独部署的可执行文件。换句话说，我的“构建器”映像永远不会离开我的本地机器，并且只需要在构建阶段访问私有回购/依赖。

对于这个解决方案，您不需要更改Dockerfile。

运行容器时，挂载~/。SSH目录(这避免了必须将键直接烘焙到映像中，而是确保它们在构建阶段只在短时间内对单个容器实例可用)。在我的例子中，我有几个构建脚本来自动化我的部署。

在我的build-and-package.sh脚本中，我像这样运行容器:

# do some script stuff before    

...

docker run --rm \
   -v ~/.ssh:/root/.ssh \
   -v "$workspace":/workspace \
   -w /workspace builder \
   bash -cl "./scripts/build-init.sh $executable"

...

# do some script stuff after (i.e. pull the built executable out of the workspace, etc.)

build-init.sh脚本如下所示:

#!/bin/bash

set -eu

executable=$1

# start the ssh agent
eval $(ssh-agent) > /dev/null

# add the ssh key (ssh key should not have a passphrase)
ssh-add /root/.ssh/id_rsa

# execute the build command
swift build --product $executable -c release

因此，我们不是直接在docker run命令中执行swift构建命令(或任何与您的环境相关的构建命令)，而是执行build-init.sh脚本，该脚本启动ssh-agent，然后将ssh密钥添加到代理，最后执行swift构建命令。

注1:为了使其工作，您需要确保您的ssh密钥没有密码短语，否则ssh-add /root/。Ssh /id_rsa行将要求口令并中断构建脚本。

注意2:确保在脚本文件上设置了适当的文件权限，以便它们可以运行。

希望这为具有类似用例的其他人提供了一个简单的解决方案。

为了在容器中注入ssh密钥，你有多种解决方案:

使用带有ADD指令的Dockerfile，你可以在构建过程中注入它 简单地执行cat id_rsa | docker run -i <image> sh -c 'cat > /root/.ssh/id_rsa' 使用docker cp命令，允许您在容器运行时注入文件。

最简单的方法是，获得一个发射台帐户并使用:ssh-import-id

一开始，有些元噪声

这里有两个得到高度好评的答案，其中有一个危险的错误建议。

我评论道，但由于我为此损失了很多天，请注意:

不要将私钥回显到文件中(意思是:回显"$ssh_prv_key" > /root/.ssh/id_ed25519)。这将破坏所需的行格式，至少在我的例子中是这样。

使用COPY或ADD代替。参见Docker加载密钥“/root/”。Ssh /id_rsa ":无效的详细格式。

另一名用户也证实了这一点:

我得到错误加载键"/root/。Ssh /id_ed25519":无效格式。回声将 为我删除换行符/双引号。这仅仅适用于ubuntu吗 或者对于alpine:3.10.3有什么不同?

---

1. 一种将私钥保存在映像中的工作方式(不太好!)

如果私钥存储在映像中，则需要注意从git网站上删除公钥，或者不发布映像。如果你处理好了，就安全了。请看下面(2.)，你也可以“忘记关注”。

Dockerfile如下所示:

FROM ubuntu:latest
RUN apt-get update && apt-get install -y git
RUN mkdir -p /root/.ssh && chmod 700 /root/.ssh
COPY /.ssh/id_ed25519 /root/.ssh/id_ed25519
RUN chmod 600 /root/.ssh/id_ed25519 && \
    apt-get -yqq install openssh-client && \
    ssh-keyscan -t ed25519 -H gitlab.com >> /root/.ssh/known_hosts
RUN git clone git@gitlab.com:GITLAB_USERNAME/test.git
RUN rm -r /root/.ssh

---

2. 一种不将私钥保存在映像中的工作方式(好!)

下面是更安全的方法，使用“多阶段构建”代替。 如果您需要一个映像，它的git repo目录中没有存储在其中一层中的私钥，那么您需要两个映像，最后只使用第二个映像。这意味着，你需要FROM两次，然后你可以只复制git回购目录从第一个映像到第二个映像，参见官方指南“使用多阶段构建”。

我们使用“alpine”作为最小的基图，使用apk代替apt-get;你也可以使用apt-get来代替上面的代码FROM ubuntu:latest。

Dockerfile如下所示:

# first image only to download the git repo
FROM alpine as MY_TMP_GIT_IMAGE

RUN apk add --no-cache git
RUN mkdir -p /root/.ssh &&  chmod 700 /root/.ssh
COPY /.ssh/id_ed25519 /root/.ssh/id_ed25519
RUN chmod 600 /root/.ssh/id_ed25519

RUN apk -yqq add --no-cache openssh-client && ssh-keyscan -t ed25519 -H gitlab.com >> /root/.ssh/known_hosts
RUN git clone git@gitlab.com:GITLAB_USERNAME/test.git
RUN rm -r /root/.ssh


# Start of the second image
FROM MY_BASE_IMAGE
COPY --from=MY_TMP_GIT_IMAGE /MY_GIT_REPO ./MY_GIT_REPO

我们在这里看到FROM只是一个名称空间，它就像它下面的行的标题，可以用别名来寻址。如果没有别名，——from=0将是第一个图像(= from命名空间)。

You could now publish or share the second image, as the private key is not in its layers, and you would not necessarily need to remove the public key from the git website after one usage! Thus, you do not need to create a new key pair at every cloning of the repo. Of course, be aware that a passwordless private key is still insecure if someone might get a hand on your data in another way. If you are not sure about this, better remove the public key from the server after usage, and have a new key pair at every run.

---

如何从Dockerfile构建映像的指南

Install Docker Desktop; or use docker inside WSL2 or Linux in a VirtualBox; or use docker in a standalone Linux partition / hard drive. Open a command prompt (PowerShell, terminal, ...). Go to the directory of the Dockerfile. Create a subfolder ".ssh/". For security reasons, create a new public and private SSH key pair - even if you already have another one lying around - for each Dockerfile run. In the command prompt, in your Dockerfile's folder, enter (mind, this overwrites without asking): Write-Output "y" | ssh-keygen -q -t ed25519 -f ./.ssh/id_ed25519 -N '""' (if you use PowerShell) or echo "y" | ssh-keygen -q -t ed25519 -f ./.ssh/id_ed25519 -N '' (if you do not use PowerShell). Your key pair will now be in the subfolder .ssh/. It is up to you whether you use that subfolder at all, you can also change the code to COPY id_ed25519 /root/.ssh/id_ed25519; then your private key needs to be in the Dockerfile's directory that you are in. Open the public key in an editor, copy the content and publish it to your server (e.g. GitHub / GitLab --> profile --> SSH keys). You can choose whatever name and end date. The final readable comment of the public key string (normally your computer name if you did not add a -C comment in the parameters of ssh-keygen) is not important, just leave it there. Start (Do not forget the "." at the end which is the build context): docker build -t test .

仅限1人使用。)

After the run, remove the public key from the server (most important, and at best at once). The script removes the private key from the image, and you may also remove the private key from your local computer, since you should never use the key pair again. The reason: someone could get the private key from the image even if it was removed from the image. Quoting a user's comment: If anyone gets a hold of your image, they can retrieve the key... even if you delete that file in a later layer, b/c they can go back to Step 7 when you added it The attacker could wait with this private key until you use the key pair again.

仅限2人。)

After the run, since the second image is the only image remaining after a build, we do not necessarily need to remove the key pair from client and host. We still have a small risk that the passwordless private key is taken from a local computer somewhere. That is why you may still remove the public key from the git server. You may also remove any stored private keys. But it is probably not needed in many projects where the main aim is rather to automate building the image, and less the security.

---

最后，更多的元噪声

对于两个高赞答案中使用了有问题的“私钥回声”方法的危险错误建议，以下是本文撰写时的投票情况:

https://stackoverflow.com/a/42125241/11154841 176个赞(前1) https://stackoverflow.com/a/48565025/11154841 55个赞(前5名) 这个问题获得了32.6万次观看，获得了376个赞

我们在这里看到答案中一定有错误，因为排名前1的答案投票至少不是在问题投票的水平上。

在排名前1的答案的评论列表的末尾，只有一个没有投票的小评论，命名了相同的私钥回声问题(在这个答案中也引用了这个问题)。而且，这一批评性评论是在给出答案三年后提出的。

I have upvoted the top 1 answer myself. I only realised later that it would not work for me. Thus, swarm intelligence is working, but on a low flame? If anyone can explain to me why echoing the private key might work for others, but not for me, please comment. Else, 326k views (minus 2 comments ;) ) would have overseen or left aside the error of the top 1 answer. I would not write such a long text here if that echo-of-the-private-key code line would not have cost me many working days, with absolutely frustrating code picking from everything on the net.

在使用Ubuntu时，ssh_config是不正确的。你需要加上

RUN  echo "    IdentityFile ~/.ssh/id_rsa" >> /etc/ssh/ssh_config

来让Dockerfile识别你的ssh密钥。