Попросите sshd перенаправить логины пользователя git в контейнер Docker (GitLab).

Я хотел бы настроить sshd на моем хост-компьютере для перенаправления логинов с открытым ключом определенного пользователя в контейнер Docker, который запускает собственную службу sshd.

Чтобы дать некоторый контекст, у меня есть GitLab, работающий в контейнере Docker, и мне не нравится открывать другой порт на хост-компьютере для связи SSH GitLab, но вместо этого sshd на хост-компьютере перенаправляет пользователя и ключ непосредственно на порт, который GitLab предоставляет на локальном компьютере. машина.

Моя идея состоит в том, чтобы сделать что-то вроде этого:

Match User git
  ForceCommand ssh -p <GitLab port> <some arguments that forward to> git@localhost
  ...

Помощь приветствуется!


git gitlab ssh docker sshd
person kwizzn    schedule 09.10.2015    source источник

Ответы (4)


arrow_upward
10
arrow_downward

Я нашел простой обходной путь к этому. Просто создайте пользователя Git на хост-компьютере и предоставьте прокси-скрипт, который выполняет заданные команды Git в контейнере GitLab, используя демон SSH хоста и .ssh/authorized_keys из тома контейнера.

  1. На хост-компьютере добавьте пользователя git, используя тот же UID и GID, что и в док-контейнере GitLab (998), и установите каталог GitLab data в качестве дома пользователя:

    useradd -u 998 -s /bin/bash -d /your/gitlab/path/data git

  2. Добавьте пользователя git в группу докеров

    usermod -G docker git

  3. Добавьте прокси-скрипт /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell на хост-компьютер со следующим содержимым:

    #!/bin/bash
docker exec -i -u git <your_gitlab_container_id> sh -c "SSH_CONNECTION='$SSH_CONNECTION' SSH_ORIGINAL_COMMAND='$SSH_ORIGINAL_COMMAND' $0 $1"
person kwizzn    schedule 23.10.2015
comment
Я добавил --env="USERMAP_UID=$((id git -u)) --env="USERMAP_GID=$((id git -g))" в команду запуска докера, чтобы избежать использования странного uid/gid (я добавил классического пользователя без -u 998) - person Vincent Fenet; 27.01.2016
comment
Вам нужно использовать docker exec -i -u git <gitlab_container> sh -c ..., иначе репозитории git будут доступны (и изменены) как root. Это на самом деле будет работать, но в конечном итоге вы столкнетесь с проблемами (например, когда вы попытаетесь отредактировать файл в репозитории с помощью веб-интерфейса Gitlab). - person Ilya Semenov; 07.06.2016
comment
Что вы подразумеваете под каталогом данных GitLab? /var/opt/gitlab ? - person Gaui; 27.09.2016
comment
Недостатком этого решения является то, что пользователь hosts git находится в группе докеров, что проблематично с точки зрения безопасности. - person Alexander Köb; 01.10.2016
comment
Я хотел бы попробовать это, но сначала я хотел бы понять третий шаг. Не могли бы вы уточнить, что он делает? Ожидается ли, что он все еще будет работать после всех этих лет? В моей системе ближайший путь — /opt/gitlab/data/gitlab-shell/, и там нет каталога bin. - person gdelfino; 16.12.2020

arrow_upward
1
arrow_downward

То, что вы предлагаете, заставит пользователей дважды аутентифицироваться. Один раз с вашим сервером и второй раз с вашим gitlab в докере, что в принципе вам не нужно.

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

Я считаю, что это возможно, но гораздо проще открыть этот порт.

Со стороны клиента вы можете сделать то же самое с ProxyCommand следующим образом:

Hostname your-gitlab
  ProxyCommand ssh -W localhost:<GitLab port> git@your-git-host
person Jakuje    schedule 09.10.2015
comment
интересно, будет ли git работать с этим. вы знаете .. gitlab предоставляет хостинг git. мне серьезно интересно, сработает ли это тогда: git clone your-gitlab:foo/bar.git - person GottZ; 10.10.2015
comment
@GottZ, почему бы и нет? Ты пытался? Это обычная практика для маршрутов с несколькими переходами. - person Jakuje; 10.10.2015
comment
@Jakuje, возможно, вы правы: это приведет к двойной аутентификации. Я мог бы с этим смириться, но не вижу простого способа поделиться файлами author_keys. Принято. :) - person kwizzn; 11.10.2015

arrow_upward
0
arrow_downward

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

command="nc -q0 gitlab 22" ssh-rsa AAAAB....[REST OF YOUR PUBKEY]

Пользователь git должен быть создан на хост-компьютере. теперь, когда вы подключаетесь с помощью «ssh git@host», это соединение должно быть перенаправлено с помощью «nc» в контейнер gitlab.

Очевидно, что это также требует, чтобы все ключи ssh gitlab были скопированы с префиксом command на хост-компьютер.

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

В моей настройке это не сработало, поскольку gitlab находится в изолированной сети, поэтому я запустил gitlab ssh на другом порту:

  • Запустите контейнер с -p 20022:22
  • добавьте gitlab_rails['gitlab_shell_ssh_port'] = 20022 в вашу конфигурацию gitlab.rb
person Alexander Köb    schedule 05.01.2017
comment
Это выглядело многообещающе, но когда я попробовал, git получает данные протокола SSH вместо ожидаемых. - person Shadow; 24.10.2020

arrow_upward
0
arrow_downward

Я пытаюсь протолкнуть свои репозитории git через свой хост на док-машину. Я немного поигрался с опцией ForceCommand. Это работает для меня ;)

Match User git
  ForceCommand ssh git@localhost -p 9022 $SSH_ORIGINAL_COMMAND
person Kippis    schedule 05.02.2018
comment
Пробовал это, не работает. Вы сделали это в SSHD на стороне хоста докера... или на стороне клиента (где находится ваш локальный репозиторий)? - person Evan R.; 11.05.2018
comment
Этот метод не работает, так как он не пересылает открытый ключ на ssh-сервер, работающий на порту 9022. - person Shadow; 24.10.2020
comment
Это работает, но есть одна загвоздка: вам нужно добавить ForwardAgent yes в файле .ssh/config на стороне клиента. - person Django Janny; 03.01.2021