Uso de claves SSH dentro del contenedor acoplable

Tengo una aplicación que ejecuta varias cosas divertidas con Git (como ejecutar git clone y git push) y estoy tratando de acoplarlo.

Sin embargo, me encuentro con un problema en el que necesito poder agregar una clave SSH al contenedor para que lo use el 'usuario' del contenedor.

Traté de copiarlo /root/.ssh/, cambiando$HOME , crear un git ssh wrapper, y aún así no suerte.

Aquí está el Dockerfile para referencia:

#DOCKER-VERSION 0.3.4                                                           

from  ubuntu:12.04                                                              

RUN  apt-get update                                                             
RUN  apt-get install python-software-properties python g++ make git-core openssh-server -y
RUN  add-apt-repository ppa:chris-lea/node.js                                   
RUN  echo "deb http://archive.ubuntu.com/ubuntu precise universe" >> /etc/apt/sources.list
RUN  apt-get update                                                             
RUN  apt-get install nodejs -y                                                  

ADD . /src                                                                       
ADD ../../home/ubuntu/.ssh/id_rsa /root/.ssh/id_rsa                             
RUN   cd /src; npm install                                                      

EXPOSE  808:808                                                                 

CMD   [ "node", "/src/app.js"]

app.js ejecuta los comandos git como git pull

Es un problema más difícil si necesita usar SSH en el momento de la compilación. Por ejemplo, si está utilizando git clone, o en mi caso pipy npmpara descargar desde un repositorio privado.

La solución que encontré es agregar tus claves usando la --build-argbandera. Luego puede usar el nuevo --squashcomando experimental (agregado 1.13) para fusionar las capas para que las claves ya no estén disponibles después de la eliminación. Aquí está mi solución:

Comando de compilación

$ docker build -t example --build-arg ssh_prv_key="$(cat ~/.ssh/id_rsa)" --build-arg ssh_pub_key="$(cat ~/.ssh/id_rsa.pub)" --squash .

Dockerfile

FROM python:3.6-slim

ARG ssh_prv_key
ARG ssh_pub_key

RUN apt-get update && \
    apt-get install -y \
        git \
        openssh-server \
        libmysqlclient-dev

# Authorize SSH Host
RUN mkdir -p /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan github.com > /root/.ssh/known_hosts

# Add the keys and set permissions
RUN echo "$ssh_prv_key" > /root/.ssh/id_rsa && \
    echo "$ssh_pub_key" > /root/.ssh/id_rsa.pub && \
    chmod 600 /root/.ssh/id_rsa && \
    chmod 600 /root/.ssh/id_rsa.pub

# Avoid cache purge by adding requirements first
ADD ./requirements.txt /app/requirements.txt

WORKDIR /app/

RUN pip install -r requirements.txt

# Remove SSH keys
RUN rm -rf /root/.ssh/

# Add the rest of the files
ADD . .

CMD python manage.py runserver

Actualización: si está utilizando Docker 1.13 y tiene características experimentales, puede agregar --squashel comando de compilación que fusionará las capas, eliminará las claves SSH y las ocultará docker history.

Resulta que cuando se usa Ubuntu, el ssh_config no es correcto. Necesitas agregar

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

a su Dockerfile para que reconozca su clave ssh.

Nota : ¡solo use este enfoque para imágenes que son privadas y siempre lo serán !

La clave ssh permanece almacenada dentro de la imagen, incluso si elimina la clave en un comando de capa después de agregarla (vea los comentarios en esta publicación ).

En mi caso, esto está bien, así que esto es lo que estoy usando:

# 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

Si está utilizando docker compose, una opción fácil es reenviar el agente SSH así:

something:
    container_name: something
    volumes:
        - $SSH_AUTH_SOCK:/ssh-agent # Forward local machine SSH key to docker
    environment:
        SSH_AUTH_SOCK: /ssh-agent

Ampliando la respuesta de Peter Grainger Pude usar la construcción en varias etapas disponible desde Docker 17.05. La página oficial dice:

Con compilaciones de varias etapas, utiliza múltiples FROMdeclaraciones en su Dockerfile. Cada FROMinstrucción puede usar una base diferente, y cada uno de ellos comienza una nueva etapa de la construcción. Puede copiar selectivamente artefactos de una etapa a otra, dejando todo lo que no desea en la imagen final.

Tener esto en cuenta aquí es mi ejemplo de Dockerfileincluir tres etapas de construcción. Está destinado a crear una imagen de producción de la aplicación web del cliente.

# Stage 1: get sources from npm and git over ssh
FROM node:carbon AS sources
ARG SSH_KEY
ARG SSH_KEY_PASSPHRASE
RUN mkdir -p /root/.ssh && \
    chmod 0700 /root/.ssh && \
    ssh-keyscan bitbucket.org > /root/.ssh/known_hosts && \
    echo "${SSH_KEY}" > /root/.ssh/id_rsa && \
    chmod 600 /root/.ssh/id_rsa
WORKDIR /app/
COPY package*.json yarn.lock /app/
RUN eval `ssh-agent -s` && \
    printf "${SSH_KEY_PASSPHRASE}\n" | ssh-add $HOME/.ssh/id_rsa && \
    yarn --pure-lockfile --mutex file --network-concurrency 1 && \
    rm -rf /root/.ssh/

# Stage 2: build minified production code
FROM node:carbon AS production
WORKDIR /app/
COPY --from=sources /app/ /app/
COPY . /app/
RUN yarn build:prod

# Stage 3: include only built production files and host them with Node Express server
FROM node:carbon
WORKDIR /app/
RUN yarn add express
COPY --from=production /app/dist/ /app/dist/
COPY server.js /app/
EXPOSE 33330
CMD ["node", "server.js"]

.dockerignorerepite el contenido del .gitignorearchivo (evita node_modulesy distse copian los directorios resultantes del proyecto):

.idea
dist
node_modules
*.log

Ejemplo de comando para construir una imagen:

$ docker build -t ezze/geoport:0.6.0 \
  --build-arg SSH_KEY="$(cat ~/.ssh/id_rsa)" \
  --build-arg SSH_KEY_PASSPHRASE="my_super_secret" \
  ./

Si su clave SSH privada no tiene una frase de contraseña, especifique un SSH_KEY_PASSPHRASEargumento vacío .

Así es como funciona:

1) Solo en la primera etapapackage.json , los yarn.lockarchivos y la clave SSH privada se copian en la primera imagen intermedia nombrada sources. Para evitar más mensajes de frase clave de SSH, se agrega automáticamente a ssh-agent. Finalmente, el yarncomando instala todas las dependencias requeridas de NPM y clona repositorios privados de git de Bitbucket sobre SSH.

2) La segunda etapa construye y minimiza el código fuente de la aplicación web y lo coloca en el distdirectorio de la siguiente imagen intermedia nombrada production. Tenga en cuenta que el código fuente de instaladonode_modules se copia de la imagen nombrada sourcesproducida en la primera etapa por esta línea:

COPY --from=sources /app/ /app/

Probablemente también podría ser la siguiente línea:

COPY --from=sources /app/node_modules/ /app/node_modules/

Sólo tenemos node_modules directorio de la primera imagen intermedia, no SSH_KEYy SSH_KEY_PASSPHRASEargumentos. Todo el resto requerido para la compilación se copia de nuestro directorio de proyectos.

3) En la tercera etapa, reducimos el tamaño de la imagen final que se etiquetará ezze/geoport:0.6.0al incluir solodist directorio de la segunda imagen intermedia nombrada productione instalar Node Express para iniciar un servidor web.

Listado de imágenes da una salida como esta:

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
ezze/geoport        0.6.0               8e8809c4e996        3 hours ago         717MB
<none>              <none>              1f6518644324        3 hours ago         1.1GB
<none>              <none>              fa00f1182917        4 hours ago         1.63GB
node                carbon              b87c2ad8344d        4 weeks ago         676MB

donde las imágenes no etiquetadas corresponden a la primera y la segunda etapa de construcción intermedia.

Si tu corres

$ docker history ezze/geoport:0.6.0 --no-trunc

no verá ninguna mención de SSH_KEYy SSH_KEY_PASSPHRASEen la imagen final.

Para inyectar su clave ssh, dentro de un contenedor, tiene múltiples soluciones:

1. Usando un Dockerfile con las ADDinstrucciones, puede inyectarlo durante su proceso de compilación

2. Simplemente haciendo algo como cat id_rsa | docker run -i <image> sh -c 'cat > /root/.ssh/id_rsa'

3. Usando el docker cpcomando que le permite inyectar archivos mientras se está ejecutando un contenedor.

Una solución multiplataforma es usar un montaje de enlace para compartir la .sshcarpeta del host con el contenedor:

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

Similar al reenvío de agentes, este enfoque hará que las claves públicas sean accesibles para el contenedor. Una ventaja adicional es que también funciona con un usuario no root y lo conectará a GitHub. Sin embargo, una advertencia a tener en cuenta es que todos los contenidos (incluidas las claves privadas) de la .sshcarpeta se compartirán, por lo que este enfoque solo es deseable para el desarrollo y solo para imágenes de contenedor confiables.

Los contenedores Docker deben verse como "servicios" propios. Para separar las preocupaciones, debe separar las funcionalidades:

1) Los datos deben estar en un contenedor de datos: use un volumen vinculado para clonar el repositorio. Ese contenedor de datos se puede vincular al servicio que lo necesita.

2) Use un contenedor para ejecutar la tarea de clonación git (es decir, su único trabajo es la clonación) vinculando el contenedor de datos cuando la ejecute.

3) Lo mismo para la clave ssh: póngalo como un volumen (como se sugirió anteriormente) y vincúlelo al servicio git clone cuando lo necesite

De esa manera, tanto la tarea de clonación como la clave son efímeras y solo están activas cuando es necesario.

Ahora, si su aplicación en sí es una interfaz git, es posible que desee considerar las API REST de github o bitbucket directamente para hacer su trabajo: para eso están diseñadas.

Esta línea es un problema:

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

Al especificar los archivos que desea copiar en la imagen, solo puede usar rutas relativas, relativas al directorio donde está su Dockerfile. Entonces deberías usar:

ADD id_rsa /root/.ssh/id_rsa

Y coloque el archivo id_rsa en el mismo directorio donde está su Dockerfile.

Mira esto para más detalles: http://docs.docker.io/reference/builder/#add

Tuvimos un problema similar al hacer la instalación de npm en el tiempo de compilación de Docker.

Inspirado en la solución de Daniel van Flymen y combinándola con git url rewrite , encontramos un método un poco más simple para autenticar la instalación de npm desde repositorios privados de github: utilizamos tokens oauth2 en lugar de las claves.

En nuestro caso, las dependencias npm se especificaron como "git + https://github.com/ ..."

Para la autenticación en el contenedor, las URL deben reescribirse para que sean adecuadas para la autenticación ssh (ssh: //git@github.com/) o la autenticación de token (https: // $ {GITHUB_TOKEN} @ github.com /)

Comando de compilación:

docker build -t sometag --build-arg GITHUB_TOKEN=$GITHUB_TOKEN . 

Desafortunadamente, estoy en Docker 1.9, por lo que la opción de squash aún no está disponible, eventualmente debe agregarse

Dockerfile:

FROM node:5.10.0

ARG GITHUB_TOKEN

#Install dependencies
COPY package.json ./

# add rewrite rule to authenticate github user
RUN git config --global url."https://${GITHUB_TOKEN}@github.com/".insteadOf "https://github.com/"

RUN npm install

# remove the secret token from the git config file, remember to use --squash option for docker build, when it becomes available in docker 1.13
RUN git config --global --unset url."https://${GITHUB_TOKEN}@github.com/".insteadOf

# Expose the ports that the app uses
EXPOSE 8000

#Copy server and client code
COPY server /server 
COPY clients /clients

Reenvíe el socket de autenticación ssh al contenedor:

docker run --rm -ti \
        -v $SSH_AUTH_SOCK:/tmp/ssh_auth.sock \
        -e SSH_AUTH_SOCK=/tmp/ssh_auth.sock \
        -w /src \
        my_image

Su guión podrá realizar a git clone.

Extra: si desea que los archivos clonados pertenezcan a un usuario específico, debe usarlos, chownya que usar otro usuario que no sea root dentro del contenedor hará que gitfalle.

Puede hacer esto publicando en el entorno del contenedor algunas variables adicionales:

docker run ...
        -e OWNER_USER=$(id -u) \
        -e OWNER_GROUP=$(id -g) \
        ...

Después de clonar, debe ejecutar chown $OWNER_USER:$OWNER_GROUP -R <source_folder>para establecer la propiedad adecuada antes de abandonar el contenedor para que un usuario no root pueda acceder a los archivos fuera del contenedor.

Como ya comentó eczajk en la respuesta de Daniel van Flymen, no parece seguro quitar las llaves y usarlas --squash, ya que aún serán visibles en el historial ( docker history --no-trunc).

En cambio, con Docker 18.09, ahora puede usar la función "construir secretos". En mi caso, cloné un repositorio privado de git usando la clave SSH de mi host con lo siguiente en mi Dockerfile:

# syntax=docker/dockerfile:experimental

[...]

RUN --mount=type=ssh git clone [...]

[...]

Para poder usar esto, debe habilitar el nuevo backend BuildKit antes de ejecutar docker build :

export DOCKER_BUILDKIT=1

Y necesitas agregar el --ssh default parámetro a docker build.

Más información sobre esto aquí: https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

Este problema es realmente molesto. Dado que no puede agregar / copiar ningún archivo fuera del contexto de dockerfile, lo que significa que es imposible vincular ~ / .ssh / id_rsa en /root/.ssh/id_rsa de la imagen, y cuando definitivamente necesita una clave para hacer algo como git clone desde un enlace de repositorio privado ..., durante la construcción de su imagen acoplable.

De todos modos, encontré una solución alternativa, no tan convincente, pero funcionó para mí.

1. en su dockerfile:

   • agregue este archivo como /root/.ssh/id_rsa
   • haz lo que quieras, como git clone, compositor ...
   • rm /root/.ssh/id_rsa al final

2. Un guión para hacer en una sesión:

   • cp su clave para la carpeta que contiene dockerfile
   • Docker Build
   • rm la clave copiada

3. cada vez que tenga que ejecutar un contenedor desde esta imagen con algunos requisitos ssh, simplemente agregue -v para el comando de ejecución, como:

   docker run -v ~ / .ssh / id_rsa: /root/.ssh/id_rsa --name comando de imagen de contenedor

Esta solución da como resultado que no haya una clave privada tanto en la fuente del proyecto como en la imagen incorporada del acoplador, por lo que ya no debe preocuparse por ningún problema de seguridad.

Me encontré con el mismo problema hoy y la versión un poco modificada con publicaciones anteriores me pareció más útil para mí.

docker run -it -v ~/.ssh/id_rsa:/root/.my-key:ro image /bin/bash

(Tenga en cuenta que solo marca para que el contenedor no ensucie mi clave ssh en ningún caso).

Dentro del contenedor ahora puedo ejecutar:

ssh-agent bash -c "ssh-add ~/.my-key; git clone <gitrepourl> <target>"

Así que no recibo ese Bad owner or permissions on /root/.ssh/..error que notó @kross

'puede permitir selectivamente que los servidores remotos accedan a su agente ssh local como si se estuviera ejecutando en el servidor'

https://developer.github.com/guides/using-ssh-agent-forwarding/

También puede vincular su directorio .ssh entre el host y el contenedor, no sé si este método tiene alguna implicación de seguridad, pero puede ser el método más fácil. Algo como esto debería funcionar:

$ sudo docker run -it -v /root/.ssh:/root/.ssh someimage bash

Recuerde que Docker se ejecuta con sudo (a menos que no lo haga), si este es el caso, usará las claves ssh raíz.

A partir de docker API 1.39+(Verifique la versión de API con docker version), --sshDocker Build permite la opción con un socket de agente o claves para permitir que Docker Engine reenvíe las conexiones de agente SSH.

Comando de construcción

export DOCKER_BUILDKIT=1
docker build --ssh default=~/.ssh/id_rsa .

Dockerfile

# syntax=docker/dockerfile:experimental
FROM python:3.7

# Install ssh client (if required)
RUN apt-get update -qq
RUN apt-get install openssh-client -y

# Download public key for github.com
RUN --mount=type=ssh mkdir -p -m 0600 ~/.ssh && ssh-keyscan github.com >> ~/.ssh/known_hosts

# Clone private repository
RUN --mount=type=ssh git clone git@github.com:myorg/myproject.git myproject

Más información:

• https://docs.docker.com/develop/develop-images/build_enhancements/#using-ssh-to-access-private-data-in-builds
• https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run---mounttypessh

Si no le importa la seguridad de sus claves SSH, aquí hay muchas buenas respuestas. Si lo hace, la mejor respuesta que encontré fue de un enlace en un comentario anterior a este comentario de GitHub por diegocsandrim . Para que otros tengan más probabilidades de verlo, y en caso de que ese repositorio desaparezca, aquí hay una versión editada de esa respuesta:

La mayoría de las soluciones aquí terminan dejando la clave privada en la imagen. Esto es malo, ya que cualquier persona con acceso a la imagen tiene acceso a su clave privada. Como no sabemos lo suficiente sobre el comportamiento desquash , este puede ser el caso incluso si elimina la clave y aplasta esa capa.

Generamos una URL de pre-firma para acceder a la clave con aws s3 cli, y limitamos el acceso durante aproximadamente 5 minutos, guardamos esta URL de pre-firma en un archivo en el directorio repo, luego en dockerfile la agregamos a la imagen.

En dockerfile tenemos un comando EJECUTAR que realiza todos estos pasos: use la URL previa al canto para obtener la clave ssh, ejecute npm install y elimine la clave ssh.

Al hacer esto en un solo comando, la clave ssh no se almacenaría en ninguna capa, pero la URL de pre-firma se almacenará, y esto no es un problema porque la URL no será válida después de 5 minutos.

El script de compilación se ve así:

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

Dockerfile se ve así:

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"]

En versiones posteriores de docker (17.05) puede usar compilaciones de varias etapas . Cuál es la opción más segura ya que las construcciones anteriores solo pueden ser utilizadas por la construcción posterior y luego se destruyen

Consulte la respuesta a mi pregunta de stackoverflow para obtener más información.

Aquí se detalla una descripción concisa de los desafíos de SSH dentro de los contenedores Docker . Para conectarse a controles remotos confiables desde un contenedor sin filtrar secretos, hay algunas maneras:

• Reenvío de agente SSH (solo Linux, no directo)
• SSH incorporado con BuildKit (Experimental, aún no compatible con Compose)
• Usando un montaje de unión para exponer ~/.sshal contenedor. (Solo desarrollo, potencialmente inseguro)
• Docker Secrets (multiplataforma, agrega complejidad)

Más allá de estos, también existe la posibilidad de usar un almacén de claves que se ejecuta en un contenedor acoplado separado accesible en tiempo de ejecución cuando se usa Compose. El inconveniente aquí es la complejidad adicional debido a la maquinaria requerida para crear y administrar un almacén de claves como Vault by HashiCorp .

Para el uso de la clave SSH en un contenedor Docker independiente, consulte los métodos vinculados anteriormente y considere los inconvenientes de cada uno según sus necesidades específicas. Sin embargo, si está ejecutando dentro de Compose y desea compartir una clave para una aplicación en tiempo de ejecución (que refleja los aspectos prácticos del OP) intente esto:

• Cree un docker-compose.envarchivo y agréguelo a su .gitignorearchivo.
• Actualice su docker-compose.ymly agregue env_filepara el servicio que requiere la clave.
• Acceda a la clave pública desde el entorno en el tiempo de ejecución de la aplicación, por ejemplo, process.node.DEPLOYER_RSA_PUBKEYen el caso de una aplicación Node.js.

El enfoque anterior es ideal para el desarrollo y las pruebas y, si bien podría satisfacer los requisitos de producción, en la producción es mejor usar uno de los otros métodos identificados anteriormente.

Recursos adicionales:

• Docker Docs: use montajes de unión
• Docker Docs: administre datos confidenciales con los secretos de Docker
• Desbordamiento de pila: uso de claves SSH dentro del contenedor acoplable
• Desbordamiento de pila: uso de ssh-agent con docker en macOS

Puede usar la compilación de varias etapas para compilar contenedores. Este es el enfoque que puede tomar:

Etapa 1 construyendo una imagen con 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

Etapa 2: construye tu contenedor

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"] 

agregue el atributo env en su archivo de redacción:

   environment:
      - SSH_PRIVATE_KEY=${SSH_PRIVATE_KEY}

luego pasa los argumentos del script de construcción de esta manera:

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

Y retire el contenedor intermedio por seguridad. Esto te ayudará a aplaudir.

Una forma simple y segura de lograr esto sin guardar su clave en una capa de imagen de Docker o pasar por la gimnasia ssh_agent es:

1. Como uno de los pasos en su Dockerfile, cree un .sshdirectorio agregando:

   RUN mkdir -p /root/.ssh

2. A continuación, eso indica que le gustaría montar el directorio ssh como un volumen:

   VOLUME [ "/root/.ssh" ]

3. Asegúrese de que su contenedor ssh_configsepa dónde encontrar las claves públicas agregando esta línea:

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

4. Exponga el .sshdirectorio del usuario local al contenedor en tiempo de ejecución:

   docker run -v ~/.ssh:/root/.ssh -it image_name

   O dockerCompose.ymlagregue esto debajo de la tecla de volumen del servicio:

   - "~/.ssh:/root/.ssh"

Su final Dockerfiledebe contener algo como:

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" ]

Estoy tratando de resolver el problema de otra manera: agregando clave ssh pública a una imagen. Pero en mis pruebas, descubrí que "docker cp" es para copiar DE un contenedor a un host. El ítem 3 en la respuesta de crujido parece estar diciendo que puede usar docker cp para inyectar archivos en un contenedor. Ver https://docs.docker.com/engine/reference/commandline/cp/

extracto

Copie archivos / carpetas del sistema de archivos de un contenedor a la ruta del host. Las rutas son relativas a la raíz del sistema de archivos.

  Usage: docker cp CONTAINER:PATH HOSTPATH

  Copy files/folders from the PATH to the HOSTPATH

Puede pasar las claves autorizadas a su contenedor utilizando una carpeta compartida y establecer permisos utilizando un archivo acoplable como este:

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

Y la ejecución de la ventana acoplable contiene algo como lo siguiente para compartir un directorio de autenticación en el host (que contiene las claves autorizadas) con el contenedor y luego abrir el puerto ssh que será accesible a través del puerto 7001 en el host.

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

Es posible que desee ver https://github.com/jpetazzo/nsenter, que parece ser otra forma de abrir un shell en un contenedor y ejecutar comandos dentro de un contenedor.

Tarde para la fiesta, sin duda, ¿qué tal esto que hará que las claves de su sistema operativo host estén disponibles para rootear dentro del contenedor, sobre la marcha:

docker run -v ~/.ssh:/mnt -it my_image /bin/bash -c "ln -s /mnt /root/.ssh; ssh user@10.20.30.40"

No estoy a favor de usar Dockerfile para instalar claves, ya que las iteraciones de su contenedor pueden dejar claves privadas.

Puede usar secretos para administrar cualquier información confidencial que un contenedor necesite en tiempo de ejecución, pero no desea almacenarla en la imagen o en el control de origen, como:

• Nombres de usuario y contraseñas
• Certificados y claves TLS
• Claves SSH
• Otros datos importantes, como el nombre de una base de datos o un servidor interno
• Cadenas genéricas o contenido binario (hasta 500 kb de tamaño)

https://docs.docker.com/engine/swarm/secrets/

Estaba tratando de descubrir cómo agregar claves de firma a un contenedor para usar durante el tiempo de ejecución (no compilar) y me encontré con esta pregunta. Los secretos de Docker parecen ser la solución para mi caso de uso, y como todavía nadie lo ha mencionado, lo agregaré.

En mi caso tuve un problema con nodejs y 'npm i' desde un repositorio remoto. Lo arreglé, agregó el usuario 'node' al contenedor de nodejs y 700 a ~ / .ssh en el contenedor.

Dockerfile:

USER node #added the part
COPY run.sh /usr/local/bin/
CMD ["run.sh"]

run.sh:

#!/bin/bash
chmod 700 -R ~/.ssh/; #added the part

docker-compose.yml:

nodejs:
      build: ./nodejs/10/
      container_name: nodejs
      restart: always
      ports:
        - "3000:3000"
      volumes:
        - ../www/:/var/www/html/:delegated
        - ./ssh:/home/node/.ssh #added the part
      links:
        - mailhog
      networks:
        - work-network

después de eso comenzó a funcionar

De la manera más simple, obtenga una cuenta de launchpad y use: ssh-import-id

En un contenedor Docker en ejecución, puede emitir ssh-keygen con la opción docker -i (interactiva). Esto reenviará las indicaciones del contenedor para crear la clave dentro del contenedor acoplable.

Para debian / root / Authorized_keys:

RUN set -x && apt-get install -y openssh-server

RUN mkdir /var/run/sshd
RUN mkdir -p /root/.ssh
RUN sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config
RUN  echo "ssh-rsa AAAA....yP3w== rsa-key-project01" >> /root/.ssh/authorized_keys
RUN chmod -R go= /root/.ssh