Назад | Перейти на главную страницу

Git: отправка через ssh в репозиторий, принадлежащий root, с отключенными логинами ssh root

это вообще возможно?

Резюме, я запускаю марионеточный мастер на сервере, и в идеале мы хотим, чтобы вход в систему с правами root через ssh был отключен, мы хотим принудительно использовать весь доступ через sudo, если требуется доступ root

однако у нас есть марионетка, установленная с использованием репозитория git для управления манифестами, это репо в настоящее время принадлежит root, и в настоящее время я знаю только 2 решения

  1. (менее идеально) разрешить root-доступ только через ключевую аутентификацию - если да, то что я могу заблокировать, чтобы разрешить только команды git push?
  2. владеете репо в / etc / puppet от имени другого владельца - будет ли puppet работать с этим надежно?
  3. Может ли соответствующая конфигурация и команда Sudo обойти это?

Репозитории Git можно настроить для поддержки разрешений на запись для группы (опция --shared при создании репозитория). Используя это, вы можете добавить любые учетные записи, которым необходим доступ к репозиторию, в определенную группу, чтобы они могли получить к нему доступ.

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

Чтобы ответить на свой вопрос, я просмотрел информацию, предоставленную Дэниелом, но она не совпала, я исследовал запись группы git и пришел к http://andyregan.net/blog/archives/504

предоставив права собственности моей группе репозитория общей группе (марионетке) и добавив соответствующих пользователей в эту группу, а затем запустив:

chmod -R g+swX /etc/puppet/
cd /etc/puppet
git repo-config core.sharedRepository true

отлично работал у меня, я могу нажать в репозиторий, принадлежащий root, марионетка все еще работает, и я не использую для этого вход в систему root ssh

Победа, Победа

ОБНОВИТЬ

У меня снова возникла эта проблема с марионеткой, но я попытался справиться с ней лучше и решил это альтернативно с помощью правильного бита конфигурации sudoers, добавив следующее после строки env_reset:

Defaults    env_keep += SSH_AUTH_SOCK

это позволяет мне запускать такую ​​команду:

cd /etc/puppet && sudo git pull && sudo git submodule sync && sudo git submodule update --init --recursive

скажем, Rakefile (у моего пользователя уже есть разрешения nopasswd через Sudo), и все работает соответственно. То, что я добился, состояло в том, чтобы передать мой ssh-агент, перенаправленный ssh-ключ, через пользователя root, а затем выполнить git pull, как если бы я был подключен как мой пользователь без полномочий root, не сохраняя свой ключ ssh под пользователем root (или мой не -привилегированный аккаунт на сервере) Win Win

Что мне нравится делать, так это иметь «промежуточное» репозиторий git на мастере марионеток, на который я нажимаю, который запускает различные хуки перед фиксацией и после фиксации. Перехватчики перед фиксацией проверяют синтаксис марионетки (чтобы код с плохим синтаксисом не мог быть зафиксирован), а перехватчики после фиксации фактически сбрасывают код в / etc / puppet и перезапускают Apache (чтобы исправить старую ошибку кеширования в марионетке 2.6)

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