Docker容器应该被视为它们自己的“服务”。为了分离关注点，你应该分离功能:

1)数据应该在数据容器中:使用链接卷将repo克隆到。然后可以将该数据容器链接到需要它的服务。

2)使用一个容器来运行git克隆任务(即它唯一的任务是克隆)，当你运行它时将数据容器链接到它。

3) ssh-key也一样:把它作为一个卷(如上所述)，当你需要它时链接到git克隆服务

这样，克隆任务和密钥都是临时的，只在需要时才活动。

现在，如果你的应用程序本身是一个git接口，你可能会考虑直接使用github或bitbucket REST api来完成你的工作:这就是它们的设计目的。

您可以使用多级构建来构建容器 你可以这样做:-

阶段1使用ssh构建映像

FROM ubuntu as sshImage
LABEL stage=sshImage
ARG SSH_PRIVATE_KEY
WORKDIR /root/temp

RUN apt-get update && \
    apt-get install -y git npm 

RUN mkdir /root/.ssh/ &&\
    echo "${SSH_PRIVATE_KEY}" > /root/.ssh/id_rsa &&\
    chmod 600 /root/.ssh/id_rsa &&\
    touch /root/.ssh/known_hosts &&\
    ssh-keyscan github.com >> /root/.ssh/known_hosts

COPY package*.json ./

RUN npm install

RUN cp -R node_modules prod_node_modules

阶段2:构建容器

FROM node:10-alpine

RUN mkdir -p /usr/app

WORKDIR /usr/app

COPY ./ ./

COPY --from=sshImage /root/temp/prod_node_modules ./node_modules

EXPOSE 3006

CMD ["npm", "run", "dev"] 

在你的合成文件中添加env属性:

   environment:
      - SSH_PRIVATE_KEY=${SSH_PRIVATE_KEY}

然后像这样从构建脚本传递参数:

docker-compose build --build-arg SSH_PRIVATE_KEY="$(cat ~/.ssh/id_rsa)"

并移除中间容器，以确保安全。 这将帮助你干杯。

我试图用另一种方式解决这个问题:向映像添加公共ssh密钥。但在我的试验中，我发现“docker cp”是用于从容器复制到主机的。creak回答的第3项似乎在说你可以使用docker cp向容器中注入文件。参见https://docs.docker.com/engine/reference/commandline/cp/

摘录

将文件/文件夹从容器的文件系统复制到主机路径。 路径相对于文件系统的根目录。 用途:docker cp CONTAINER:PATH HOSTPATH 将PATH中的文件/文件夹复制到HOSTPATH中

一开始，有些元噪声

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

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

不要将私钥回显到文件中(意思是:回显"$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.

一个简单而安全的方法来实现这一点，而不需要将密钥保存在Docker镜像层中，或通过ssh_agent体操:

As one of the steps in your Dockerfile, create a .ssh directory by adding: RUN mkdir -p /root/.ssh Below that indicate that you would like to mount the ssh directory as a volume: VOLUME [ "/root/.ssh" ] Ensure that your container's ssh_config knows where to find the public keys by adding this line: RUN echo " IdentityFile /root/.ssh/id_rsa" >> /etc/ssh/ssh_config Expose you local user's .ssh directory to the container at runtime: docker run -v ~/.ssh:/root/.ssh -it image_name Or in your dockerCompose.yml add this under the service's volume key: - "~/.ssh:/root/.ssh"

你最终的Dockerfile应该包含如下内容:

FROM node:6.9.1

RUN mkdir -p /root/.ssh
RUN  echo "    IdentityFile /root/.ssh/id_rsa" >> /etc/ssh/ssh_config

VOLUME [ "/root/.ssh" ]

EXPOSE 3000

CMD [ "launch" ]

这一行是个问题:

ADD ../../home/ubuntu/.ssh/id_rsa /root/.ssh/id_rsa

当指定要复制到映像中的文件时，只能使用相对路径——相对于Dockerfile所在的目录。所以你应该用:

ADD id_rsa /root/.ssh/id_rsa

将id_rsa文件放到Dockerfile所在的目录中。

查看更多详细信息:http://docs.docker.io/reference/builder/#add