Usando chaves SSH dentro do contêiner de janela de encaixe

Eu tenho um aplicativo que executa várias coisas divertidas com o Git (como executar o git clone e git push) e estou tentando encaixá-lo.

Estou enfrentando um problema, no qual preciso adicionar uma chave SSH ao contêiner para o usuário 'contêiner' usar.

Tentei copiá-lo /root/.ssh/, mudar $HOME, criar um invólucro git ssh, e ainda sem sorte.

Aqui está o Dockerfile para referência:

#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 executa os comandos git como git pull

É um problema mais difícil se você precisar usar o SSH no momento da construção. Por exemplo, se você estiver usando git clone, ou no meu caso, pipe npmbaixar de um repositório particular.

A solução que encontrei é adicionar suas chaves usando a --build-argbandeira. Em seguida, você pode usar o novo --squashcomando experimental (adicionado 1.13) para mesclar as camadas para que as chaves não fiquem mais disponíveis após a remoção. Aqui está a minha solução:

Comando Build

$ 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

Atualização: se você estiver usando o Docker 1.13 e tiver recursos experimentais, poderá anexar --squashao comando build que mesclará as camadas, removendo as chaves SSH e ocultando-as docker history.

Acontece que ao usar o Ubuntu, o ssh_config não está correto. Você precisa adicionar

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

ao seu Dockerfile para que ele reconheça sua chave ssh.

Nota : use esta abordagem apenas para imagens privadas e sempre serão !

A chave ssh permanece armazenada na imagem, mesmo se você remover a chave em um comando de camada depois de adicioná-la (consulte os comentários nesta postagem ).

No meu caso, está tudo bem, então é isso que estou 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

Se você estiver usando o docker composer, uma escolha fácil é encaminhar o agente SSH assim:

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

Expandindo a resposta de Peter Grainger, eu pude usar a compilação de vários estágios disponível desde o Docker 17.05. Página oficial afirma:

Com compilações de vários estágios, você usa várias FROMinstruções no Dockerfile. Cada FROMinstrução pode usar uma base diferente e cada uma delas inicia uma nova etapa da construção. Você pode copiar artefatos seletivamente de um estágio para outro, deixando para trás tudo o que não deseja na imagem final.

Mantendo isso em mente aqui é o meu exemplo de Dockerfileinclusão de três estágios de construção. Ele foi criado para criar uma imagem de produção do aplicativo Web 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"]

.dockerignorerepete o conteúdo do .gitignorearquivo (impede node_modulesque os distdiretórios resultantes do projeto sejam copiados):

.idea
dist
node_modules
*.log

Exemplo de comando para criar uma imagem:

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

Se sua chave SSH privada não tiver uma senha, basta especificar o SSH_KEY_PASSPHRASEargumento vazio .

É assim que funciona:

1) Somente no primeiro estágio package.json, os yarn.lockarquivos e a chave SSH privada são copiados para a primeira imagem intermediária denominada sources. Para evitar mais solicitações de senha de chave SSH, ela é automaticamente adicionada ssh-agent. Finalmente, o yarncomando instala todas as dependências necessárias do NPM e clona os repositórios git privados do Bitbucket sobre SSH.

2) O segundo estágio cria e reduz o código fonte do aplicativo Web e o coloca no distdiretório da próxima imagem intermediária denominada production. Observe que o código fonte do instalado node_modulesé copiado da imagem nomeada sourcesproduzida no primeiro estágio por esta linha:

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

Provavelmente também poderia ser a seguinte linha:

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

Temos apenas o node_modulesdiretório da primeira imagem intermediária aqui, não SSH_KEYe SSH_KEY_PASSPHRASEmais argumentos. Todo o restante necessário para a construção é copiado do diretório do projeto.

3) No terceiro estágio, reduzimos o tamanho da imagem final que será marcada, ezze/geoport:0.6.0incluindo apenas o distdiretório da segunda imagem intermediária denominada productione instalando o Node Express para iniciar um servidor da web.

A listagem de imagens fornece uma saída 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

onde imagens sem etiqueta correspondem aos primeiro e segundo estágios de construção intermediários.

Se você correr

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

você não verá nenhuma menção de SSH_KEYe SSH_KEY_PASSPHRASEna imagem final.

Para injetar sua chave ssh, em um contêiner, você tem várias soluções:

1. Usando um Dockerfile com a ADDinstrução, você pode injetá-lo durante o processo de compilação

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

3. Usando o docker cpcomando que permite injetar arquivos enquanto um contêiner está em execução.

Uma solução de plataforma cruzada é usar uma montagem de ligação para compartilhar a .sshpasta do host no contêiner:

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

Semelhante ao encaminhamento do agente, essa abordagem tornará as chaves públicas acessíveis ao contêiner. Uma vantagem adicional é que ele também funciona com um usuário não root e o conectará ao GitHub. Uma ressalva a considerar, no entanto, é que todo o conteúdo (incluindo chaves privadas) da .sshpasta será compartilhado, portanto essa abordagem é apenas desejável para o desenvolvimento e apenas para imagens de contêineres confiáveis.

Os contêineres do Docker devem ser vistos como 'serviços' próprios. Para separar preocupações, você deve separar as funcionalidades:

1) Os dados devem estar em um contêiner de dados: use um volume vinculado para clonar o repositório. Esse contêiner de dados pode ser vinculado ao serviço que precisa dele.

2) Use um contêiner para executar a tarefa de clonagem git (ou seja, é apenas o trabalho que está clonando) vinculando o contêiner de dados a ele quando você o executar.

3) O mesmo para a chave ssh: coloque um volume (como sugerido acima) e vincule-o ao serviço de clone do git quando você precisar

Dessa forma, a tarefa de clonagem e a chave são efêmeras e ativas apenas quando necessário.

Agora, se o aplicativo em si for uma interface git, convém considerar as APIs REST do github ou bitbucket diretamente para fazer seu trabalho: é para isso que elas foram projetadas.

Esta linha é um problema:

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

Ao especificar os arquivos que você deseja copiar para a imagem, você só pode usar caminhos relativos - em relação ao diretório em que está o Dockerfile. Então você deve usar:

ADD id_rsa /root/.ssh/id_rsa

E coloque o arquivo id_rsa no mesmo diretório em que está o seu Dockerfile.

Verifique isso para obter mais detalhes: http://docs.docker.io/reference/builder/#add

Tivemos um problema semelhante ao fazer a instalação do npm no tempo de construção do docker.

Inspirados na solução de Daniel van Flymen e combinando-a com a reescrita de git url , descobrimos um método um pouco mais simples para autenticar a instalação do npm a partir de repositórios particulares do github - usamos tokens oauth2 em vez das chaves.

No nosso caso, as dependências do npm foram especificadas como "git + https://github.com/ ..."

Para autenticação no contêiner, os URLs precisam ser reescritos para serem adequados para autenticação ssh (ssh: //git@github.com/) ou autenticação de token (https: // $ {GITHUB_TOKEN} @ github.com /)

Comando Build:

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

Infelizmente, estou no docker 1.9, então a opção --squash ainda não está lá, eventualmente ela precisa ser adicionada

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

Encaminhe o soquete de autenticação ssh para o contêiner:

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

Seu script poderá executar a git clone.

Extra: se você deseja que os arquivos clonados pertençam a um usuário específico, é necessário usar, chownpois o uso de outro usuário que não seja root dentro do contêiner fará com que gitfalhe.

Você pode fazer esta publicação no ambiente do contêiner algumas variáveis ​​adicionais:

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

Depois de clonar, você deve executar chown $OWNER_USER:$OWNER_GROUP -R <source_folder>para definir a propriedade adequada antes de sair do contêiner, para que os arquivos sejam acessíveis por um usuário não raiz fora do contêiner.

Como o eczajk já comentou na resposta de Daniel van Flymen, não parece seguro remover as chaves e usá-las --squash, pois elas ainda serão visíveis na história ( docker history --no-trunc).

Em vez disso, com o Docker 18.09, agora você pode usar o recurso "construir segredos". No meu caso, clonei um repositório Git privado usando a chave SSH dos meus hosts com o seguinte no meu Dockerfile:

# syntax=docker/dockerfile:experimental

[...]

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

[...]

Para poder usar isso, é necessário ativar o novo back-end BuildKit antes da execução docker build:

export DOCKER_BUILDKIT=1

E você precisa adicionar o --ssh defaultparâmetro para docker build.

Mais informações sobre isso aqui: https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

Esta questão é realmente irritante. Como você não pode adicionar / copiar nenhum arquivo fora do contexto do dockerfile, isso significa que é impossível vincular ~ / .ssh / id_rsa ao /root/.ssh/id_rsa da imagem e quando você definitivamente precisa de uma chave para executar alguma coisa de sshed como o git clone de um link de repo privado ..., durante a construção da sua imagem do docker.

Enfim, encontrei uma solução para a solução alternativa, não tão convincente, mas funcionou para mim.

1. no seu arquivo docker:

   • adicione este arquivo como /root/.ssh/id_rsa
   • faça o que quiser, como git clone, compositor ...
   • rm /root/.ssh/id_rsa no final

2. um script para fazer em uma sessão:

   • cp sua chave para a pasta que contém o dockerfile
   • docker build
   • rm a chave copiada

3. sempre que você precisar executar um contêiner a partir desta imagem com alguns requisitos ssh, basta adicionar -v para o comando run, como:

   docker execute -v ~ / .ssh / id_rsa: /root/.ssh/id_rsa --name comando imagem de contêiner

Essa solução não resulta em nenhuma chave privada na imagem do docker e na imagem do docker, portanto, não há mais problema de segurança com o que se preocupar.

Encontrei o mesmo problema hoje e uma versão modificada com posts anteriores achei essa abordagem mais útil para mim

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

(Observe que o sinalizador somente leitura para que o contêiner não mexa na minha chave ssh em nenhum caso.)

Agora, dentro do contêiner, posso executar:

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

Portanto, não recebo o Bad owner or permissions on /root/.ssh/..erro que foi observado por @kross

'você pode permitir seletivamente que os servidores remotos acessem seu agente ssh local como se estivesse em execução no servidor'

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

Você também pode vincular seu diretório .ssh entre o host e o contêiner. Não sei se esse método tem implicações de segurança, mas pode ser o método mais fácil. Algo assim deve funcionar:

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

Lembre-se de que a janela de encaixe é executada com o sudo (a menos que você não faça isso), se esse for o caso, você usará as teclas ssh raiz.

A partir de docker API 1.39+(Verificar versão da API com docker version) docker build permite a --sshopção com um soquete ou chaves de agente para permitir que o Docker Engine encaminhe as conexões do agente SSH.

Comando Build

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

Mais informações:

• 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

Se você não se importa com a segurança de suas chaves SSH, há muitas boas respostas aqui. Em caso afirmativo, a melhor resposta que encontrei foi de um link no comentário acima para este comentário do GitHub por diegocsandrim . Para que outros tenham maior probabilidade de vê-lo, e no caso de esse repositório desaparecer, aqui está uma versão editada dessa resposta:

A maioria das soluções aqui acaba deixando a chave privada na imagem. Isso é ruim, pois qualquer pessoa com acesso à imagem tem acesso à sua chave privada. Como não sabemos o suficiente sobre o comportamento desquash , isso ainda pode ser o caso, mesmo se você excluir a chave e esmagar essa camada.

Geramos uma URL de pré-assinatura para acessar a chave com o aws s3 cli e limitamos o acesso por cerca de 5 minutos, salvamos essa URL de pré-assinatura em um arquivo no diretório repo e, em dockerfile, a adicionamos à imagem.

No dockerfile, temos um comando RUN que executa todas estas etapas: use a URL de pré-gravação para obter a chave ssh, execute o npm install e remova a chave ssh.

Ao fazer isso em um único comando, a chave ssh não seria armazenada em nenhuma camada, mas a URL de pré-assinatura será armazenada, e isso não é um problema, porque a URL não será válida após 5 minutos.

O script de construção se parece com:

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

O Dockerfile fica assim:

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

Nas versões posteriores do docker (17.05), você pode usar construções de vários estágios . Qual é a opção mais segura, pois as compilações anteriores só podem ser usadas pela compilação subsequente e são destruídas

Veja a resposta à minha pergunta sobre o stackoverflow para obter mais informações

Uma visão geral concisa dos desafios do SSH nos contêineres do Docker é detalhada aqui . Para conectar-se a controles remotos confiáveis ​​a partir de um contêiner sem vazar segredos, existem algumas maneiras:

• Encaminhamento de agente SSH (somente Linux, não direto)
• SSH embutido com BuildKit (experimental, ainda não suportado pelo Compose)
• Usando uma montagem de ligação para expor ~/.sshao contêiner. (Somente desenvolvimento, potencialmente inseguro)
• Segredos do Docker (multiplataforma, aumenta a complexidade)

Além desses, há também a possibilidade de usar um armazenamento de chaves em execução em um contêiner de docker separado, acessível em tempo de execução ao usar o Compose. A desvantagem aqui é a complexidade adicional devido ao mecanismo necessário para criar e gerenciar um keystore, como o Vault da HashiCorp .

Para uso da chave SSH em um contêiner do Docker independente, consulte os métodos vinculados acima e considere as desvantagens de cada um, dependendo de suas necessidades específicas. Se, no entanto, você estiver executando o Compose e quiser compartilhar uma chave para um aplicativo em tempo de execução (refletindo os aspectos práticos do OP), tente o seguinte:

• Crie um docker-compose.envarquivo e adicione-o ao seu .gitignorearquivo.
• Atualize docker-compose.ymle adicione o env_fileserviço que requer a chave.
• Acesse a chave pública do ambiente no tempo de execução do aplicativo, por exemplo, process.node.DEPLOYER_RSA_PUBKEYno caso de um aplicativo Node.js.

A abordagem acima é ideal para desenvolvimento e teste e, embora possa atender aos requisitos de produção, na produção é melhor usar um dos outros métodos identificados acima.

Recursos adicionais:

• Documentos do Docker: use montagens de ligação
• Docker Docs: gerencie dados confidenciais com segredos do Docker
• Estouro de pilha: Usando chaves SSH dentro do contêiner de janela de encaixe
• Estouro de pilha: Usando o ssh-agent com docker no macOS

Você pode usar a construção de vários estágios para construir contêineres É a abordagem que você pode seguir: -

Estágio 1: construindo uma imagem com 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: construa seu contêiner

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

adicione o atributo env no seu arquivo de composição:

   environment:
      - SSH_PRIVATE_KEY=${SSH_PRIVATE_KEY}

depois passe argumentos do script de construção como este:

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

E remova o contêiner intermediário por segurança. Isso irá ajudá-lo a aplausos.

Uma maneira simples e segura de conseguir isso sem salvar sua chave em uma camada de imagem do Docker ou passar pela ginástica ssh_agent é:

1. Como uma das etapas no seu Dockerfile, crie um .sshdiretório adicionando:

   RUN mkdir -p /root/.ssh

2. Abaixo disso, indique que você deseja montar o diretório ssh como um volume:

   VOLUME [ "/root/.ssh" ]

3. Verifique se o contêiner ssh_configsabe onde encontrar as chaves públicas adicionando esta linha:

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

4. Exponha o .sshdiretório do usuário local ao contêiner em tempo de execução:

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

   Ou dockerCompose.ymladicione-o na chave de volume do serviço:

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

Sua final Dockerfiledeve conter 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" ]

Estou tentando resolver o problema de outra maneira: adicionando a chave ssh pública a uma imagem. Mas, em meus testes, descobri que "docker cp" é para copiar de um contêiner para um host. O item 3 da resposta por creak parece estar dizendo que você pode usar o docker cp para injetar arquivos em um contêiner. Consulte https://docs.docker.com/engine/reference/commandline/cp/

excerto

Copie arquivos / pastas do sistema de arquivos de um contêiner para o caminho do host. Os caminhos são relativos à raiz do sistema de arquivos.

  Usage: docker cp CONTAINER:PATH HOSTPATH

  Copy files/folders from the PATH to the HOSTPATH

Você pode passar as chaves autorizadas para o contêiner usando uma pasta compartilhada e definir permissões usando um arquivo docker 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

E sua execução do docker contém algo como o seguinte para compartilhar um diretório de autenticação no host (segurando as teclas authorised_keys) com o contêiner e abrir a porta ssh que poderá ser acessada através da porta 7001 no host.

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

Você pode consultar https://github.com/jpetazzo/nsenter, que parece ser outra maneira de abrir um shell em um contêiner e executar comandos dentro de um contêiner.

É tardio para a parte, que tal isso, que disponibilizará as chaves do sistema operacional do host para fazer root dentro do contêiner, em tempo real:

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

Não sou a favor de usar o Dockerfile para instalar chaves, pois as iterações do seu contêiner podem deixar as chaves privadas para trás.

Você pode usar segredos para gerenciar quaisquer dados confidenciais que um contêiner precisa em tempo de execução, mas não deseja armazenar na imagem ou no controle de origem, como:

• Nomes de usuário e senhas
• Certificados e chaves TLS
• Chaves SSH
• Outros dados importantes, como o nome de um banco de dados ou servidor interno
• Sequências genéricas ou conteúdo binário (tamanho de até 500 kb)

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

Eu estava tentando descobrir como adicionar chaves de assinatura a um contêiner para usar durante o tempo de execução (não compilar) e me deparei com essa pergunta. Os segredos do Docker parecem ser a solução para o meu caso de uso e, como ninguém o mencionou ainda, eu o adicionarei.

No meu caso, tive um problema com o nodejs e o 'npm i' de um repositório remoto. Corrigi-o adicionado usuário 'node' ao container nodejs e 700 ao ~ / .ssh no container.

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

depois disso começou a funcionar

De maneira mais simples, obtenha uma conta da barra de ativação e use: ssh-import-id

Em um contêiner de docker em execução, você pode emitir ssh-keygen com a opção docker -i (interativa). Isso encaminhará as solicitações do contêiner para criar a chave dentro do contêiner do Docker.

Para debian / root / allowed_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