Gitolite One User - много ключей - разные имена пользователей

Ответ 1

Рекомендуемый текущий курс в соответствии с документацией

"Самое простое и понятное - поставить свои ключи в разные подкаталоги [внутри вашего /kedir ], (alice.pub, home/alice.pub, ноутбук /alice.pub и т.д.).

ссылка: http://gitolite.com/gitolite/gitolite.html#multi-key

Старый способ

Если вы спрашиваете, как выполнить следующее:

• Дэвид (домашний компьютер)
• Дэвид (рабочий компьютер)
• Дэвид (ноутбук)

С помощью разных ключей ssh ​​на каждом компьютере вы просто создадите ключ (то есть: keygen "[email protected]" ), а затем скопируйте открытый ключ в свой каталог gitolite keydir (gitolite-admin/keydir). Когда вы это сделаете, просто назовите ключ [email protected], [email protected] и [email protected]. Добавьте ключи в репозиторий (git add keydir/.), зафиксируйте (git commit -m "added David additional keys") и git push обратно на сервер.

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

Надеюсь, что это поможет

Чтобы исправить сценарий, в котором у вас может быть john_home.pub john_work.pub, откройте свое репозиторинг gitolite (admin repo) и переименуйте ключи в своих kedir в [email protected] и [email protected] фиксации и нажмите. Теперь ваш пользователь john может войти с любого компьютера и использовать одно и то же имя пользователя.

Имейте в виду, для того, чтобы это работало, адрес электронной почты в SSH-ключах должен быть одинаковым для всех пользовательских ключей. Поэтому, используя приведенный выше пример, в ключах [email protected], [email protected] и [email protected] все должны иметь адрес электронной почты [email protected].

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

Ответ 2

Для гитолита v3 по крайней мере Самое простое решение - использовать описанную здесь систему подпапок http://sitaramc.github.com/gitolite/users.html

Gitolite будет искать рекурсивно через keydir и связывать все .pub как один пользователь. Теперь я использую систему вложенных папок с ноутбуком Windows и операционной системой Linux и отлично работаю.

Соглашение пользователя @host кажется слишком сложным.

Я делаю что-то вроде этого:

keydir
 |--mfang
 |    |--laptop01
 |    |      |--mfang.pub
 |    |--linux01
 |    |      |--mfang.pub
 |...etc

Ответ 3

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

В общем, я предпочитаю не использовать один, плоский каталог, содержащий все ключи, полагаясь исключительно на соглашение об именах "[email protected]", чтобы все было в порядке. (Это, по-видимому, подразумевается в других ответах?) Это может запутать, если у вас несколько ключей на нескольких хостах и ​​несколько имен пользователей для одного "реального" пользователя (или даже одного и того же имени пользователя для двух разных пользователей на двух разных хостах). Использование подкаталогов помогает организовать вещи - используя дерево любой глубины, но обычно я просто использую один уровень.

Два основных варианта (или даже их комбинация):

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

В качестве примера одного подкаталога для каждого пользователя (вариант # 1):

conf
 |--gitolite.conf
keydir
 |--john.doe
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |--will.rodgers
 |    |--wrodgers.pub
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |...etc

Обратите внимание, что:

• имена каталогов (под keydir) не имеют значения для гитолита.
• имя каталога должно быть универсальным, например, адресом электронной почты или другим глобальным идентификатором. Это позволяет пользователям git с потенциально одинаковым именем пользователя на разных хостах.
• ключ, например "user.pub" или "[email protected]", может совместно использоваться пользователем через несколько хостов; однако это может быть обескуражено на основе политики.

В общем, я предпочитаю и использую опцию №1, посыпанную несколькими примерами опции №2. Вариант № 2 может упростить автоматизацию интрасети, если у вас есть серверы, которые идут и идут (возможно, инициализация и переработка виртуальных машин) и хотят поддерживать работу на уровне хоста, а не на уровне пользователя, поэтому вы можете (например) легко очистить устаревшие ключи на выведенном из строя узле (например, краткосрочная тестовая ВМ).

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

Ответ 4

Поскольку гитолит v3.5.2-10-g437b497 (сентябрь 2013 г., совершает 59c817d0), существует еще более простое решение:

ukm, для "управления ключами пользователей" .

Управление ключевыми словами позволяет некоторым пользователям добавлять и удалять ключи.

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

Это также облегчает добавление/удаление открытых ключей ssh.

Вы можете увидеть это в действии в contrib/t/ukm.t":

Документация Gitolite содержит раздел по этому вопросу, но с ukm, это проще (раздел " Пользователи, которые хотят управлять несколькими ключами):

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

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

# The admin can add multiple keys for the same userid.
try "
ADDOK u5 admin u4\@example.org
ADDOK u5 admin u4\@example.org\@home
ADDOK u5 admin laptop/u4\@example.org
ADDOK u5 admin laptop/u4\@example.org\@home
";

Ответ 5

Вы устанавливаете гитолит под одним пользователем на сервере; обычно git, а в строке подключения SSH вы всегда явно используете [email protected] для подключения к учетной записи пользователя Git. Затем Gitolite посмотрит, какой открытый ключ вы предлагаете, найдите в своей конфигурации и обработайте, как будто вы являетесь ассоциированным пользователем.

Ответ 6

Вы всегда подключаетесь следующим образом:

git clone [email protected]:reponame

независимо от того, кем вы являетесь. Gitolite идентифицирует вас тем, какой открытый ключ вы предоставляете. Например, этот ключ называется dave.pub. Все, что делается через ssh-соединение с этим открытым ключом, будет проверено gitolite в соответствии с тем, где в файле конфигурации используется "dave" или "all".

Вы можете указать имя и адрес электронной почты как раз то, что вы хотите на разных машинах и разных репозиториях. Коммиты будут иметь эту информацию. Но какая ветка, дерево или репозитории, которые вы можете читать или записывать в/из, диктуется тем, как "dave" ограничен в файле конфигурации в репозитории администратора - если вы используете тот же общедоступный/закрытый ключ для ssh.

Надеюсь, это поможет.

Ответ 7

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

OP задал вопрос, как обращаться с тем же PERSON, используя два разных USERNAMES и два разных (связанных) паб-ключа на двух разных PLATFORMS.

Eg. [email protected]_a.pub и [email protected]_b.pub оба представляют один и тот же реальный пользователь git.

Достаточно просто добавить как dave, так и david в качестве пользователей на строке "@known" (известные пользователи) в файле gitolite.conf и поместить оба ключа в keydir, но тогда нет способа сказать будь то два отдельных пользователя или один и тот же человек.

Eg. "git винить" будет относиться к dave и david как к двум отдельным пользователям.

Помимо сообщения OP, дальнейшее осложнение - это то, что происходит, если в одном проекте работает несколько Davids?

Я думаю, что соответствующие Дэвидс должны были бы разработать систему (или быть довольным, чтобы обвинять друг друга;).

Ответ 8

Gitolite выполняет аутентификацию с помощью принудительных команд ssh. Каждый пользователь, имеющий доступ к репозиторию gitolite, регистрируется при использовании этого гитолита. Крючки берут новые ключи в keydir и добавляют их в файл авторизованных ключей, сконфигурированный для использования принудительных команд.

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

my $user = $f;
$user =~ s(.*/)();                # foo/bar/baz.pub -> baz.pub
$user =~ s/(\@[^.]+)?\.pub$//;    # baz.pub, [email protected] -> baz

Это обеспечивает функциональность как таковую:

keydir
  |--host1
       |--dave.pub
       |--david.pub
  |--host2
       |--dave.pub

Каталоги произвольны, но для организационных целей хосты используются для создания структуры. В итоге у вас есть два пользователя dave и один пользователь david.

Я использую следующую конфигурацию:

keydir
  |--steve
       |[email protected]@laptop.pub
       |[email protected]@desktop.pub
  |--services
       |--jenkins
            |[email protected]
            |[email protected]
       |--redmine
            |[email protected]
       |--jira
            |[email protected]

Опять же, структура каталогов не имеет значения. Это дает мне пользователи [email protected], jenkins, redmine и jira. Пользователь [email protected] имеет два ключа, а также пользователь jenkins. Если бы у меня было больше одного пользователя, у меня, вероятно, был бы подкаталог пользователей, содержащий каталог ключей steve.