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

Question

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

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

Если у меня есть две клиентские машины, для использования одним реальным человеком, но на каждой из этих машин имена пользователей, скажем, dave и david. Как организовать ключи в keydir и любом файле конфигурации, чтобы они оба представляли одного и того же пользователя? Я получаю суффикс, dave @ laptop, dave @ desktop (я думаю), но не о том, как соединять разные имена пользователей клиентских машин, как кажется, это происходит при аутентификации (возможно, из-за открытого ключа, содержащего информацию user @ host) ?)

Я могу дать больше подробностей, если это необходимо - я просто не хотел бомбардировать вас всех ненужной информацией.

Большое спасибо.

Answer 1

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

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

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

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

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

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

Используя разные ключи ssh на каждом компьютере, вы просто создаете ключ (например, keygen "david@someemail.com") и затем копируете открытый ключ в каталог gitolite keydir (gitolite-админ / keydir).Когда вы это сделаете, просто назовите ключи david@homecomputer.pub, david@workcomputer.pub и david@laptop.pub.Добавьте ключи в репозиторий (git add keydir/.), commit (git commit -m "added David's additional keys") и git push обратно на сервер.

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

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

Исправить сценарий, в котором вы могли бы иметьjohn_home.pub john_work.pub откройте репозиторий gitolite (admin repo) и переименуйте ключи в kedir в john@work.pub и john@home.pub commit и push.Теперь ваш пользователь john может войти в систему с любого компьютера и использовать одно и то же имя пользователя.

Имейте в виду, чтобы это работало, адрес электронной почты в ключах SSH должен быть одинаковым для всехключи пользователя.Таким образом, используя приведенный выше пример, в ключах david@homecomputer.pub, david@workcomputer.pub и david@laptop.pub все должны иметь адрес электронной почты david@foobar.com.

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

Answer 2

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

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

Соглашение user @ host кажется слишком сложным.

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

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

Answer 3

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

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

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

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

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

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

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

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

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

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

Answer 4

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

В общем, я предпочитаю , а не , чтобы использовать один плоский каталог со всеми ключами, полагаясь исключительно на соглашение об именах "user@host.pub", чтобы все было понятно. (Похоже, это подразумевается в других ответах?) Это может сбить с толку, если у вас есть несколько ключей на нескольких хостах и ​​несколько имен пользователей для одного «реального» пользователя (или даже одно и то же имя пользователя для двух разных пользователей на двух разных хостах). Использование подкаталогов помогает упорядочить вещи - используя дерево любой глубины, но обычно я просто использую один уровень.

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

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

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

conf
 |--gitolite.conf
keydir
 |--john.doe
 |    |--john@host1.pub
 |    |--john@host2.pub
 |    |--jdoe@host2.pub
 |    |--john.doe@company.com.pub
 |    |--tester@temp-vm43.pub
 |--will.rodgers
 |    |--wrodgers.pub
 |    |--wrodg1234@host2.pub
 |    |--will.rodgers@company.com.pub
 |    |--tester@temp-vm22.pub
 |...etc

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

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

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

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

Answer 5

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

ОП спросил, как обращаться с одним и тем же ЛИЦОМ, используя два разных ИМЕНА ПОЛЬЗОВАТЕЛЯ и два разных (связанных) паб-ключа на двух разных ПЛАТФОРМАХ.

Например. dave@platform_a.pub и david@platform_b.pub оба представляют одного и того же реального пользователя git.

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

Например. "git blame" будет рассматривать Дэйва и Дэвида как двух отдельных пользователей.

Помимо должности ОП, дальнейшее осложнение заключается в том, что произойдет, если над одним проектом работают несколько Давидов?

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

Answer 6

Вы всегда подключаетесь так:

git clone gitoliteuser@gitoliteserver:reponame

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

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

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

Answer 7

Вы устанавливаете gitolite под одним пользователем на сервере; обычно git, а в строке подключения SSH вы всегда явно используете git@servername для подключения к учетной записи пользователя Git. Затем Gitolite рассмотрит, какой открытый ключ вы предлагаете, найдет его в вашей конфигурации и будет обращаться с вами, как с ассоциированным пользователем.

Answer 8

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

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

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

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

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

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

Я использую конфигурацию, похожую на эту:

keydir
  |--steve
       |--steve@example.com@laptop.pub
       |--steve@example.com@desktop.pub
  |--services
       |--jenkins
            |--jenkins@master-buildhost.pub
            |--jenkins@slave-buildhost.pub
       |--redmine
            |--redmine@dev-server.pub
       |--jira
            |--jira@dev-alias.pub

Опять же, структура каталогов не имеет значения. Это дает мне пользователей steve@example.com, jenkins, redmine и jira. У пользователя steve@example.com есть две клавиши, а также у пользователя jenkins. Если бы у меня было больше одного пользователя, я бы, вероятно, имел подкаталог users, содержащий каталог ключей steve.