Управление открытыми ключами SSH в репозиториях GitHub. - PullRequest
21 голосов
/ 17 августа 2011

Мне было интересно, есть ли у кого-нибудь хороший, чистый и безопасный способ управления доступом к репозиторию github Organisation на своих серверах?

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

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

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

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

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

Я весь в ушах, если кто-либохотел бы поделиться чем-то, что имеет / работает для их организации github.

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

Ответы [ 4 ]

7 голосов
/ 05 марта 2012

Альтернативой ответу от sergey_mo (и как прямой ответ на последний вопрос Михаэля Шайбе) является создание нескольких ключей ssh, как описано chalien на githib:

https://gist.github.com/jexchan/2351996

3 голосов
/ 17 августа 2011

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

Обычным способом GitHub было бы добавить всех соавторов и просто иметь стабильный проект и бета-форк. Вы автоматически перетащите текущую бета-версию на свой бета-сервер для тестирования (там не нужен ssh-ключ), и если ваши тесты пройдут успешно, вы перенесете слияния с бета-форка в стабильный проект.

2 голосов
/ 31 января 2012

Небольшая заметка о КИ:
Например, если вы используете Jenkins и вам это нужно для доступа к более чем 1 проекту, вам потребуется:
1. добавить открытый ключ в одну учетную запись пользователя github
2. добавьте этого пользователя в качестве владельца (для доступа ко всем проектам) или в качестве коллаборатора в каждом проекте.

Многие открытые ключи для одного системного пользователя не будут работать, потому что GitHub найдет первый соответствующий ключ развертывания и отправит сообщение об ошибке, например "ОШИБКА: разрешение пользователю / repo2 отклонено для пользователя / repo1"

http://help.github.com/ssh-issues/

0 голосов
/ 27 августа 2011

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

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

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

...