У меня есть следующий вариант использования: я хотел бы иметь возможность git@git.company.com:gitolite-admin
использовать личный ключ пользователя gitolite-admin
, в то время как я хочу git@git.company.com:some_repo
использовать собственный ключ. AFAIK, я не могу решить это с помощью ~/.ssh/config
, потому что имя пользователя и имя сервера идентичны в обоих случаях. Поскольку я в основном использую свой собственный закрытый ключ, я определил его в ~/.ssh/config
for git@git.company.com
. Кто-нибудь знает способ переопределить ключ, который используется для одного git
вызова?
(Кроме того, gitolite различает, кто выполняет нажатие на основе ключа, поэтому с точки зрения доступа, владения и аудита не проблема, что строка user @ server одинакова для разных пользователей.)
Ответы:
Даже если пользователь и хост совпадают, их все равно можно различить
~/.ssh/config
. Например, если ваша конфигурация выглядит следующим образом:Тогда вы просто используете
gitolite-as-alice
иgitolite-as-bob
вместо имени хоста в вашем URL:Заметка
Вы хотите включить опцию,
IdentitiesOnly yes
чтобы предотвратить использование идентификаторов по умолчанию. В противном случае, если у вас также есть идентификаторы, совпадающие с именами по умолчанию, они будут опробованы в первую очередь, потому что в отличие от других параметров конфигурации (которые учитывают «сначала в выигрышах»),IdentityFile
опция добавляется в список идентификаторов, которые нужно попробовать. См .: /server/450796/how-could-i-stop-ssh-offering-a-wrong-key/450807#450807источник
git@
Часть в пульте дистанционного управления не является необходимой , как оно дано вUser
строке конфигурации.IdentitiesOnly yes
сразу после строкиIdentityFile
для хоста. Кажется, он передавал несколько идентификаторов, и один из них был заблокирован от доступа к хосту.Альтернативный подход, предложенный Марком Лонгэйром выше, заключается в использовании псевдонима, который будет запускать любую команду git на любом удаленном компьютере с альтернативным ключом SSH. Идея в основном состоит в том, чтобы переключать вашу личность SSH при запуске команд git.
Преимущества относительно подхода псевдонима хоста в другом ответе:
remote
явно.Я использую несколько небольших скриптов и псевдоним git
admin
. Таким образом, я могу сделать, например:Чтобы нажать на пульт по умолчанию, используя альтернативный ("admin") ключ SSH. Опять же, вы можете использовать любую команду (не только
push
) с этим псевдонимом. Вы могли бы даже сделатьgit admin clone ...
клонирование хранилища, к которому у вас был бы доступ только с помощью вашего ключа «admin».Шаг 1: Создайте альтернативные ключи SSH, при желании установите пароль, если вы делаете это на чужой машине.
Шаг 2: Создайте скрипт с именем «ssh-as.sh», который запускает материал, который использует SSH, но использует заданный ключ SSH, а не по умолчанию:
Шаг 3: Создайте скрипт с именем «git-as.sh», который запускает команды git с использованием данного ключа SSH.
Шаг 4: Добавьте псевдоним (используя что-то подходящее для «PATH_TO_SCRIPTS_DIR» ниже):
Более подробная информация на: http://noamlewis.wordpress.com/2013/01/24/git-admin-an-alias-for-running-git-commands-as-a-privileged-ssh-identity/
источник
$@
->"$@"
чтобы быть в безопасности.Вы можете использовать переменную окружения git
GIT_SSH_COMMAND
. Запустите это в своем терминале под своим репозиторием git:Замените
~/.ssh/your_private_key
путь к секретному ключу ssh, который вы хотите использовать. И вы можете изменить последующую команду git (в примере естьgit submodule update --init
) на другие, напримерgit pull
,git fetch
и т. Д.источник
В системах на основе Unix (Linux, BSD, Mac OS X) идентификатор по умолчанию хранится в каталоге $ HOME / .ssh в 2 файлах:
private key: $HOME/.ssh/id_rsa public key: $HOME/.ssh/id_rsa.pub
при использованииssh
без параметра-i
используется закрытый ключ по умолчанию для аутентификации на удаленной системе.Если у вас есть другой закрытый ключ, который вы хотите использовать, например, $ HOME / .ssh / deploy_key , вы должны использовать
ssh -i ~/.ssh/deploy_key ...
Это раздражает. Вы можете добавить следующие строки в ваш $ HOME / .bash_profile :
ssh-add ~/.ssh/deploy_key ssh-add ~/.ssh/id_rsa
Поэтому каждый раз, когда вы используете
ssh
илиgit
илиscp
(в основномssh
тоже), вам больше не нужно использовать опцию-i
.Вы можете добавить столько ключей, сколько захотите, в файле $ HOME / .bash_profile .
источник
Другой альтернативой является использование ssh-идент для управления вашими ssh-идентичностями .
Он автоматически загружает и использует различные ключи в зависимости от вашего текущего рабочего каталога, параметров ssh и т. Д. ... это означает, что вы можете легко иметь каталог work / directory и private /, который прозрачно в конечном итоге использует различные ключи и идентификаторы с ssh.
источник
Я использую Git Bash на Win7. Следующее сработало для меня.
Создайте файл конфигурации в ~ / .ssh / config или в c: / users / [your_user_name] /. Ssh / config. В файле введите:
Я думаю, что хост должен быть URL-адресом, а не просто именем или ссылкой для вашего хоста. Например,
Путь также может быть записан в формате / c / users / [user_name] / ....
Решение, предоставленное Джордано Скальцо, также великолепно. https://stackoverflow.com/a/9149518/1738546
источник
Начиная с git 2.10 и выше, также можно использовать настройку gitconfig sshCommand. Документы утверждают :
Пример использования будет:
git config core.sshCommand "ssh -i ~/.ssh/[insert_your_keyname]
В некоторых случаях это не работает, потому что ssh_config переопределяет команду, в этом случае старайтесь
ssh -i ~/.ssh/[insert_your_keyname] -F /dev/null
не использовать ssh_config.источник
Я собрал вместе и протестировал с github следующий подход, основанный на чтении других ответов, который сочетает в себе несколько приемов:
Преимущество этого подхода в том, что после настройки он не требует дополнительной работы для правильной настройки - например, вам не нужно менять удаленные URL-адреса или помнить, что нужно клонировать объекты по-другому - перезапись URL-адреса делает все это работоспособным ,
~/.ssh/config
~/.gitconfig
~/dev/work/.gitconfig
Пока вы храните все свои рабочие репозитории в ~ / dev / work и личные вещи в других местах, git будет использовать правильный SSH-ключ при выполнении команды pull / clones / pushes на сервере, а также будет прикреплять правильный адрес электронной почты ко всем ваши коммиты.
Ссылки:
1
2
источник
includeIf
должен работать, только если есть.git
каталог, который я подумал?При использовании sit-версии Git для Windows строка файла идентификации в конфигурации ssh выглядит так:
где
/c
дляc:
Чтобы проверить, в Git's Bash сделать
источник
Возможно, вам придется удалить (или закомментировать) конфигурацию хоста по умолчанию
источник
Вы больше всего указали в файле конфигурации ключ ssh:
источник
Как уже упоминалось,
core.sshCommand
config может использоваться для переопределения ключа SSH и других параметров.Вот пример, где у вас есть альтернативный ключ с именем
~/.ssh/workrsa
и вы хотите использовать его для всех клонированных репозиториев~/work
..gitconfig
файл в разделе~/work
:~/.gitconfig
добавьте:источник
Одной из возможностей использования
~/.ssh/config
является использованиеMatch
ограничения вместоHost
ограничения. В частности,Match Exec
вызывает команду оболочки, чтобы решить, применять ли объявления или нет. В bash вы можете использовать следующую команду:Это использует команду bash,
[
чтобы проверить, равны ли две строки. В этом случае он проверяет, соответствует ли строкаgit@git.company.com:gitolite-admin
выводу, полученному из$(git config --get remote.origin.url)''
команды.Вы можете использовать любую другую команду, которая идентифицирует хранилище, в котором находится оболочка. Для этого важно, чтобы
$SHELL
в моем случае была определена переменная для вашей оболочки/bin/bash
. Полный пример будет следующим~/.ssh/config
:В этом примере я предположил, что он
~/.ssh/yourOwnPrivateKey
содержит ваш собственный закрытый ключ и который~/.ssh/gitolite-admin
содержит закрытый ключ пользователяgitolite-admin
. Я включилIdentitiesOnly yes
декларацию, чтобы убедиться, что на git-сервер предлагается только один ключ, упомянутый Марком Лонгэйром . Другие объявления - это просто стандартные опции ssh для git.Вы можете добавить эту конфигурацию, если у вас есть несколько,
some_repo
которые вы хотите использовать с разными ключами. Если у вас есть несколько репозиториев,git@git.company.com
и большинство из них используют,~/.ssh/yourOwnPrivateKey
имеет смысл включить этот ключ по умолчанию для хоста. В этом случае~/.ssh/config
будет:Обратите внимание, что порядок имеет значение, и
Host git.company.com
ограничение должно появиться послеMatch Exec
одного или одного.источник
Настройте свой репозиторий, используя
git config
. Например:источник