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

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

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

注意:只使用这种方法的图像是私有的，将永远是!

ssh密钥仍然存储在映像中，即使您在添加密钥后在层命令中删除密钥(参见本文中的评论)。

在我的情况下，这是可以的，所以这是我使用的:

# Setup for ssh onto github
RUN mkdir -p /root/.ssh
ADD id_rsa /root/.ssh/id_rsa
RUN chmod 700 /root/.ssh/id_rsa
RUN echo "Host github.com\n\tStrictHostKeyChecking no\n" >> /root/.ssh/config

我把一个非常简单的解决方案放在一起，它适用于我的用例，我使用一个“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密钥。但在我的试验中，我发现“docker cp”是用于从容器复制到主机的。creak回答的第3项似乎在说你可以使用docker cp向容器中注入文件。参见https://docs.docker.com/engine/reference/commandline/cp/

摘录

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

如果您不关心SSH密钥的安全性，这里有许多很好的答案。如果你有，我找到的最好的答案是从上面一个评论的链接到这个GitHub评论由diegosandrim。所以其他人更有可能看到它，以防回购消失，这里是这个答案的编辑版本:

这里的大多数解决方案最终都将私钥保留在映像中。这很糟糕，因为任何访问映像的人都可以访问您的私钥。由于我们对挤压的行为了解不够，即使你删除键并挤压该层，情况仍然可能是这样。

我们用aws s3 cli生成一个预签名URL来访问密钥，并限制访问大约5分钟，我们将这个预签名URL保存到repo目录下的一个文件中，然后在dockerfile中将其添加到映像中。

在dockerfile中，我们有一个RUN命令，执行所有这些步骤:使用pre-sing URL获取ssh密钥，运行npm install，并删除ssh密钥。

通过在单个命令中执行此操作，ssh密钥将不会存储在任何层中，但将存储预签名URL，这不是问题，因为URL将在5分钟后失效。

构建脚本看起来像:

# build.sh
aws s3 presign s3://my_bucket/my_key --expires-in 300 > ./pre_sign_url
docker build -t my-service .

Dockerfile是这样的:

FROM node

COPY . .

RUN eval "$(ssh-agent -s)" && \
    wget -i ./pre_sign_url -q -O - > ./my_key && \
    chmod 700 ./my_key && \
    ssh-add ./my_key && \
    ssh -o StrictHostKeyChecking=no git@github.com || true && \
    npm install --production && \
    rm ./my_key && \
    rm -rf ~/.ssh/*

ENTRYPOINT ["npm", "run"]

CMD ["start"]

你可以通过共享文件夹将授权密钥传递到你的容器中，并使用docker文件设置权限，如下所示:

FROM ubuntu:16.04
RUN apt-get install -y openssh-server
RUN mkdir /var/run/sshd
EXPOSE 22
RUN cp /root/auth/id_rsa.pub /root/.ssh/authorized_keys
RUN rm -f /root/auth
RUN chmod 700 /root/.ssh
RUN chmod 400 /root/.ssh/authorized_keys
RUN chown root. /root/.ssh/authorized_keys
CMD /usr/sbin/sshd -D

您的docker运行包含如下内容，与容器共享主机上的认证目录(持有authorised_keys)，然后打开ssh端口，该端口将通过主机上的端口7001访问。

-d -v /home/thatsme/dockerfiles/auth:/root/auth -–publish=127.0.0.1:7001:22

您可能想要查看https://github.com/jpetazzo/nsenter，它似乎是打开容器上的shell并在容器中执行命令的另一种方式。