Использование ключей SSH внутри контейнера Docker

У меня есть приложение, которое выполняет различные забавные вещи с помощью Git (например, запуск git clone & git push), и я пытаюсь сделать это в docker-ize.

Однако я сталкиваюсь с проблемой, когда мне нужно иметь возможность добавить ключ SSH в контейнер для контейнера, который должен использовать пользователь.

Я попытался скопировать его /root/.ssh/, изменив$HOME , создать оболочку git ssh, но все равно не повезло.

Вот Dockerfile для справки:

#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 запускает команды git как git pull

Это более сложная проблема, если вам нужно использовать SSH во время сборки. Например, если вы используете git clone, или в моем случае pipиnpm для загрузки из частного хранилища.

Решение, которое я нашел, состоит в том, чтобы добавить ваши ключи, используя --build-argфлаг. Затем вы можете использовать новую экспериментальную --squashкоманду (добавлена ​​1.13), чтобы объединить слои, чтобы ключи больше не были доступны после удаления. Вот мое решение:

Команда построения

$ 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

Обновление: если вы используете Docker 1.13 и у вас есть экспериментальные функции, вы можете добавить --squashкоманду build, которая объединит слои, удаляя ключи SSH и скрывая их от docker history.

Оказывается, при использовании Ubuntu ssh_config не верен. Вам нужно добавить

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

в ваш Dockerfile, чтобы он распознал ваш ключ 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

Если вы используете docker compose , простой способ - перенаправить SSH-агент следующим образом:

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

Расширяя ответ Питера Грейнджера, я смог использовать многоступенчатую сборку, доступную с Docker 17.05. Официальная страница гласит:

В многоэтапных сборках вы используете несколько FROMоператоров в вашем Dockerfile. Каждая FROMинструкция может использовать различную базу, и каждая из них начинает новый этап сборки. Вы можете выборочно копировать артефакты с одного этапа на другой, оставляя после себя все, что вам не нужно, в конечном изображении.

Имея это в виду, вот мой пример Dockerfileвключения трех этапов сборки. Он предназначен для создания производственного образа клиентского веб-приложения.

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

.dockerignoreповторяет содержимое .gitignoreфайла (предотвращает копирование node_modulesи последующие distкаталоги проекта):

.idea
dist
node_modules
*.log

Пример команды для построения изображения:

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

Если ваш закрытый ключ SSH не имеет парольной фразы, просто укажите пустой SSH_KEY_PASSPHRASE аргумент.

Вот как это работает:

1). Только на первом этапеpackage.json , yarn.lockфайлы и секретный ключ SSH копируются первым промежуточным изображением имени sources. Чтобы избежать дальнейших запросов парольной фразы ключа SSH, она автоматически добавляется в ssh-agent. в заключениеyarn команда устанавливает все необходимые зависимости от NPM и клонирует частные репозитории git из Bitbucket через SSH.

2). Второй этап создает и минимизирует исходный код веб-приложения и помещает его в distкаталог следующего промежуточного изображения с именем production. Обратите внимание, что исходный код установленnode_modules скопирован из образа с именем, sourcesсозданным на первом этапе этой строкой:

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

Возможно, это также может быть следующая строка:

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

У нас есть только node_modules каталог из первого промежуточного изображения здесь, нет SSH_KEYиSSH_KEY_PASSPHRASE аргументов больше. Все остальное, необходимое для сборки, скопировано из каталога нашего проекта.

3). На третьем этапе мы уменьшаем размер конечного изображения, которое будет помечено как ezze/geoport:0.6.0включающее толькоdist каталог из второго промежуточного изображения с именем productionи устанавливая Node Express для запуска веб-сервера.

Список изображений дает вывод, как это:

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

где немаркированные изображения соответствуют первому и второму промежуточным этапам сборки.

Если вы бежите

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

Вы не увидите никаких упоминаний SSH_KEYи SSH_KEY_PASSPHRASEв конечном изображении.

Чтобы ввести ваш ключ ssh, в контейнере у вас есть несколько решений:

1. Используя Dockerfile с ADDинструкцией, вы можете добавить его во время процесса сборки

2. Просто делать что-то вроде cat id_rsa | docker run -i <image> sh -c 'cat > /root/.ssh/id_rsa'

3. Использование docker cpкоманды, которая позволяет вводить файлы во время работы контейнера.

Одним из кроссплатформенных решений является использование привязки для совместного использования .sshпапки хоста с контейнером:

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

Подобно переадресации агента, этот подход сделает открытые ключи доступными для контейнера. Дополнительным преимуществом является то, что он работает и с пользователем без полномочий root и подключит вас к GitHub. Однако следует учесть, что все содержимое (включая закрытые ключи) из .sshпапки будет общим, поэтому этот подход желателен только для разработки и только для доверенных образов контейнера.

Контейнеры Docker следует рассматривать как собственные «сервисы». Чтобы разделить проблемы, вы должны разделить функции:

1) Данные должны находиться в контейнере данных: используйте связанный том, чтобы клонировать репо. Затем этот контейнер данных может быть связан с сервисом, которому он нужен.

2) Используйте контейнер для запуска задачи клонирования git (т. Е. Это только клонирование задания), связывая контейнер данных с ним при запуске.

3) То же самое для ssh-ключа: поместите это том (как предложено выше) и свяжите его со службой git clone, когда вам это нужно

Таким образом, и задача клонирования, и ключ являются эфемерными и активными только при необходимости.

Теперь, если само ваше приложение представляет собой интерфейс git, вы можете рассмотреть возможность использования API-интерфейсов REST github или bitbucket непосредственно для своей работы: для этого они и были разработаны.

Эта строка является проблемой:

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

У нас была похожая проблема при установке npm во время сборки Docker.

Вдохновленный решением от Daniel van Flymen и объединив его с git url rewrite , мы нашли немного более простой способ аутентификации установки npm из частных репозиториев github - мы использовали токены oauth2 вместо ключей.

В нашем случае зависимости npm были указаны как "git + https://github.com/ ..."

Для аутентификации в контейнере необходимо переписать URL-адреса, чтобы они подходили для аутентификации ssh (ssh: //git@github.com/) или для аутентификации токена (https: // $ {GITHUB_TOKEN} @ github.com /)

Команда построения:

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

К сожалению, я нахожусь на докере 1.9, поэтому опции --squash еще нет, в конце концов ее нужно добавить

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

Перешлите сокет аутентификации ssh в контейнер:

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

Ваш сценарий сможет выполнить git clone .

Дополнительно: если вы хотите, чтобы клонированные файлы принадлежали определенному пользователю, вам нужно использовать, chownтак как использование другого пользователя, кроме root, внутри контейнера сделаетgit сбою.

Вы можете сделать эту публикацию в среде контейнера некоторых дополнительных переменных:

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

После клонирования вы должны выполнить chown $OWNER_USER:$OWNER_GROUP -R <source_folder>установку правильного владельца, прежде чем покинуть контейнер, чтобы файлы были доступны пользователю без полномочий root вне контейнера.

Как уже прокомментировал eczajk в ответе Даниеля ван Флаймена, извлекать ключи и использовать --squashих небезопасно , так как они все еще будут видны в истории ( docker history --no-trunc).

Вместо этого с Docker 18.09 вы можете теперь использовать функцию «строить секреты». В моем случае я клонировал частное git-репо, используя мой SSH-ключ hosts, со следующим в моем Dockerfile:

# syntax=docker/dockerfile:experimental

[...]

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

[...]

Чтобы использовать это, вам нужно включить новый бэкэнд BuildKit перед запуском docker build:

export DOCKER_BUILDKIT=1

И вам нужно добавить --ssh defaultпараметр в docker build.

Больше информации об этом здесь: https://medium.com/@tonistiigi/build-secrets-and-ssh-forwarding-in-docker-18-09-ae8161d066

Эта проблема действительно раздражает. Поскольку вы не можете добавить / скопировать какой-либо файл вне контекста dockerfile, это означает, что невозможно просто связать ~ / .ssh / id_rsa в /root/.ssh/id_rsa изображения, и когда вам определенно нужен ключ для выполнения каких-либо sshed как git clone из приватной ссылки репо ... во время создания вашего образа докера.

В любом случае, я нашел решение обходного пути, не настолько убедительное, но сработало для меня.

1. в вашем докер-файле:

   • добавить этот файл как /root/.ssh/id_rsa
   • делай что хочешь, например git clone, composer ...
   • rm /root/.ssh/id_rsa в конце

2. скрипт, который нужно сделать за один раз:

   • cp ваш ключ к папке, содержащей файл dockerfile
   • сборка докера
   • рм скопированный ключ

3. каждый раз, когда вам нужно запустить контейнер из этого образа с некоторыми требованиями ssh, просто добавьте -v для команды run, например:

   docker запустите -v ~ / .ssh / id_rsa: /root/.ssh/id_rsa - имя команды контейнера изображения

Это решение не приводит к закрытому ключу ни в исходном проекте, ни во встроенном образе докера, поэтому больше не нужно беспокоиться о безопасности.

Я столкнулся с той же проблемой сегодня и немного модифицированной версии с предыдущими постами, я нашел этот подход более полезным для меня

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

(Обратите внимание, что флаг readonly, поэтому контейнер ни в коем случае не испортит мой ключ ssh.)

Внутри контейнера теперь я могу запустить:

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

Так что я не понимаю ту Bad owner or permissions on /root/.ssh/..ошибку, которая была замечена @kross

«Вы можете выборочно разрешить удаленным серверам обращаться к вашему локальному ssh-агенту, как если бы он работал на сервере»

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

Вы также можете связать каталог .ssh между хостом и контейнером, я не знаю, имеет ли этот метод какие-либо последствия для безопасности, но это может быть самый простой метод. Примерно так должно работать:

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

Помните, что docker запускается с помощью sudo (если вы этого не делаете), в этом случае вы будете использовать корневые ssh-ключи.

Начиная с docker API 1.39+(проверьте версию API с помощью docker version) сборки docker, вы можете --sshвыбрать опцию с сокетом агента или ключами, чтобы Docker Engine мог перенаправлять соединения агента SSH.

Команда сборки

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

Больше информации:

• 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

Если вы не заботитесь о безопасности своих ключей SSH, здесь есть много хороших ответов. Если да, лучший ответ, который я нашел, был по ссылке в комментарии выше на этот комментарий GitHub от diegocsandrim . Так что другие с большей вероятностью увидят это, и на случай, если репо когда-нибудь исчезнет, ​​вот отредактированная версия этого ответа:

Большинство решений в конечном итоге оставляют закрытый ключ в изображении. Это плохо, так как любой, имеющий доступ к изображению, имеет доступ к вашему личному ключу. Поскольку мы недостаточно знаем о поведенииsquash , это все равно может иметь место, даже если вы удалите ключ и раздавите этот слой.

Мы генерируем предварительный URL-адрес для доступа к ключу с помощью aws s3 cli и ограничиваем доступ примерно на 5 минут. Мы сохраняем этот предварительный URL-адрес в файле в каталоге репо, затем в dockerfile добавляем его к изображению.

В dockerfile у нас есть команда RUN, которая выполняет все эти шаги: используйте предварительно введенный 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 (17.05) вы можете использовать многоэтапные сборки . Какой самый безопасный вариант, так как предыдущие сборки могут быть использованы только последующими, а затем уничтожены

См. Ответ на мой вопрос stackoverflow для получения дополнительной информации

Краткий обзор проблем SSH внутри контейнеров Docker подробно описан здесь . Для подключения к доверенным удаленным устройствам из контейнера без утечки секретов существует несколько способов:

• Переадресация агента SSH (только для Linux, а не прямо)
• Встроенный SSH с BuildKit (экспериментальный, пока не поддерживается Compose)
• Использование привязного крепления для экспонирования ~/.sshв контейнер. (Только разработка, потенциально небезопасно)
• Docker Secrets (кроссплатформенный, добавляет сложности)

Помимо этого есть также возможность использовать хранилище ключей, работающее в отдельном контейнере Docker, доступном во время выполнения при использовании Compose. Недостатком здесь является дополнительная сложность из-за механизма, необходимого для создания и управления хранилищем ключей, такого как Vault от HashiCorp .

Для использования ключа SSH в автономном контейнере Docker см. Методы, указанные выше, и рассмотрите недостатки каждого из них в зависимости от ваших конкретных потребностей. Однако, если вы работаете внутри Compose и хотите поделиться ключом к приложению во время выполнения (отражая практические возможности OP), попробуйте это:

• Создайте docker-compose.envфайл и добавьте его в свой .gitignoreфайл.
• Обновите свой docker-compose.ymlи добавьте env_fileдля службы, требующей ключ.
• Доступ к открытому ключу из среды во время выполнения приложения, например, process.node.DEPLOYER_RSA_PUBKEYв случае приложения Node.js.

Вышеуказанный подход идеален для разработки и тестирования, и, хотя он может удовлетворить производственные требования, на производстве вам лучше использовать один из других методов, указанных выше.

Дополнительные ресурсы:

• Докер Документы: Используйте привязные крепления
• Docker Docs: управление конфиденциальными данными с секретами Docker
• Переполнение стека: использование ключей SSH внутри контейнера докера
• Переполнение стека: использование ssh-agent с докером в macOS

Вы можете использовать многоэтапную сборку для построения контейнеров. Это подход, который вы можете использовать:

Стадия 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 в ваш файл compose:

   environment:
      - SSH_PRIVATE_KEY=${SSH_PRIVATE_KEY}

затем передайте аргументы из сценария сборки следующим образом:

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

И удалите промежуточный контейнер для безопасности. Это поможет вам ура.

Простой и безопасный способ добиться этого без сохранения ключа в слое изображения Docker или прохождения гимнастики ssh_agent:

1. В качестве одного из шагов в вашем Dockerfile, создайте .sshкаталог, добавив:

   RUN mkdir -p /root/.ssh

2. Ниже указано, что вы хотите смонтировать каталог ssh как том:

   VOLUME [ "/root/.ssh" ]

3. Убедитесь, что ваш контейнер ssh_configзнает, где найти открытые ключи, добавив следующую строку:

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

4. Предоставьте .sshкаталог локального пользователя контейнеру во время выполнения:

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

   Или в вашем dockerCompose.ymlдобавить это под ключ громкости службы:

   - "~/.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" ]

Я пытаюсь решить проблему другим способом: добавить открытый ключ ssh к изображению. Но в своих испытаниях я обнаружил, что "docker cp" предназначен для копирования из контейнера на хост. Пункт 3 в ответе скрипит, кажется, говорит, что вы можете использовать docker cp для внедрения файлов в контейнер. См. Https://docs.docker.com/engine/reference/commandline/cp/.

выдержка

Скопируйте файлы / папки из файловой системы контейнера в путь к хосту. Пути указаны относительно корня файловой системы.

  Usage: docker cp CONTAINER:PATH HOSTPATH

  Copy files/folders from the PATH to the HOSTPATH

Вы можете передать авторизованные ключи в свой контейнер с помощью общей папки и установить разрешения с помощью файла 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

И ваш докерский прогон содержит что-то вроде следующего для совместного использования каталога auth на хосте (содержащего authorised_keys) с контейнером, после чего откройте порт ssh, который будет доступен через порт 7001 на хосте.

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

Возможно, вы захотите взглянуть на https://github.com/jpetazzo/nsenter, который является еще одним способом открыть оболочку в контейнере и выполнить команды внутри контейнера.

По общему признанию поздней вечеринки, как об этом, что сделает ключи операционной системы вашего хоста доступными для root внутри контейнера, на лету:

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

Я не одобряю использование Dockerfile для установки ключей, поскольку итерации вашего контейнера могут оставить закрытые ключи позади.

Вы можете использовать секреты для управления любыми конфиденциальными данными, которые нужны контейнеру во время выполнения, но вы не хотите хранить их в изображении или в управлении исходным кодом, например:

• Имена пользователей и пароли
• TLS сертификаты и ключи
• SSH ключи
• Другие важные данные, такие как имя базы данных или внутреннего сервера
• Общие строки или двоичное содержимое (размером до 500 КБ)

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

Я пытался выяснить, как добавить ключи подписи в контейнер для использования во время выполнения (не сборки), и наткнулся на этот вопрос. Секреты докера, похоже, являются решением для моего варианта использования, и, поскольку никто еще не упомянул об этом, я добавлю его.

В моем случае у меня была проблема с nodejs и 'npm i' из удаленного репозитория. Я исправил добавление пользователя 'node' в контейнер nodejs и 700 в ~ / .ssh в контейнер.

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

докер-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

после этого начались работы

Проще всего получить учетную запись панели запуска и использовать: ssh-import-id

В работающем контейнере Docker вы можете запустить ssh-keygen с опцией docker -i (интерактивный). Это переадресует запросы контейнера для создания ключа внутри контейнера докера.

Для 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