Во-первых, позаботьтесь о том, чтобы ваша команда ssh отправляла ваш «идентификатор GitHub» (действительно: ключ) в GitHub, а вашу «идентификатор Bitbucket» - в Bitbucket. Это означает, что ваша ssh конфигурация 1 (не конфигурация Git!) Будет включать:
Host github.com
IdentityFile ~/.ssh/id_rso
IdentitiesOnly yes
(последняя строка не обязательна, но это хорошая идея) и:
Host bitbucket.org
IdentityFile ~/.ssh/id_rsa
IdentitiesOnly yes
(при условии, что у меня есть правильные идентификационные файлы). Затем используйте ssh://git@github.com/path/to/repo.git и ssh://git@bitbucket.com/path/to/repo.git в качестве URL для ваших двух пультов (вы можете использовать синтаксис git@$hostingsite:path, если хотите, это не имеет значения, мне просто нравится сам синтаксис ssh://). Отдельные пульты будут оставаться отдельными, и вы будете получать или нажимать только на каждый, как вы говорите Git, чтобы получать или нажимать на каждый.
Технические примечания
Технически, ни GitHub, ни Bitbucket не используют вашу учетную запись электронной почты. Ну, они оба используют его, но для отправки вам электронной почты , а не для идентификации некоторого потока входящих данных как «вы». Они также используют его для идентификации коммитов, «сделанных вами», для демонстрации; но такие коммиты могут быть введены кем-то другим.
В частности, когда вы используете SSH для подключения к или Bitbucket или GitHub, вы запускаете неинтерактивный эквивалент:
ssh -T git@$hostingsite
, где $hostingsite равно bitbucket.org или github.com. Это означает, что вы просите эти системы войти в систему как пользователь с именем git, а не как вы! Так откуда они знают, что вы вы?
Остальная часть этого обсуждения действительно о том, как работает Gitolite
В приведенном ниже описании предполагается линейное сканирование всего файла authorized_keys, которое, вероятно, слишком медленное для занятых серверов Bitbucket и GitHub. Принципы должны быть одинаковыми, хотя. Система Gitolite буквально работает таким образом, чтобы работать на неизмененных серверах Unix / Linux.
Пользователь git в этих системах не может делать очень много. Однако этот конкретный пользователь имеет очень длинный файл authorized_keys, который вместо обычных ssh-rsa AAAA... строк содержит строки, начинающиеся с: 2
restrict,command="<path>/gl-auth-command <user>" ssh-rsa AAAA...
Когда сервер sshd на машине принимает входящий ключ и сопоставляет его с открытым ключом, хранящимся в файле authorized_keys пользователя git, эта командная строка с ограничениями и специальными командами заставляет его запускать что-то другое чем универсальная оболочка. В этом конкретном примере мы указываем как путь к этапу авторизации Gitolite, так и имя пользователя, которого ssh только что авторизовал на основе этого ключа .
Запрос, отправленный вашим Git на выполнение git upload-pack или аналогичный, сохраняется в переменной окружения ($ORIGINAL_SSH_COMMAND). Следовательно, только что выполненная команда знает , чей ключ, который позволил вам ввести , вместе с тем, какую операцию Git вы просили выполнить (если вы попросили сделать одну, если нет, вы получите это "успешно авторизовано, но "сообщение, которое $hostingsite печатает).
Существует дополнительное обсуждение в Запуск «безопасного» сервера git по SSH без gitosis / gitolite? и в это superuser.com Q & A .
1 Файл конфигурации ssh обычно называется $HOME/.ssh/config.
2 Я использую restrict здесь, а не кропотливо перечисляя все возможности ssh для отключения. Я думаю, что некоторые старые версии sshd не поддерживают restrict, следовательно, более длинные версии в связанных вопросах.