Укажите ключ SSH для git push для данного домена

У меня есть следующий вариант использования: я хотел бы иметь возможность нажать на git@git.company.com:gitolite-admin используя закрытый ключ пользователя gitolite-adminпока хочу подтолкнуть к git@git.company.com:some_repo используя "мой собственный" закрытый ключ. AFAIK, я не могу решить это с помощью ~/.ssh/configпотому что имя пользователя и имя сервера идентичны в обоих случаях. Поскольку я в основном использую свой собственный закрытый ключ, я определил это в ~/.ssh/config за git@git.company.com, Кто-нибудь знает способ переопределить ключ, который используется для одного git вызов?

(Кроме того, gitolite различает, кто выполняет нажатие на основе ключа, поэтому с точки зрения доступа, владения и аудита не проблема, что строка user@server одинакова для разных пользователей.)

Источник

19 ответов

Решение

Даже если пользователь и хост совпадают, их все равно можно различить в ~/.ssh/config, Например, если ваша конфигурация выглядит так:

Host gitolite-as-alice
  HostName git.company.com
  User git
  IdentityFile /home/whoever/.ssh/id_rsa.alice
  IdentitiesOnly yes

Host gitolite-as-bob
  HostName git.company.com
  User git
  IdentityFile /home/whoever/.ssh/id_dsa.bob
  IdentitiesOnly yes

Тогда вы просто используете gitolite-as-alice а также gitolite-as-bob вместо имени хоста в вашем URL:

git remote add alice git@gitolite-as-alice:whatever.git
git remote add bob git@gitolite-as-bob:whatever.git

Заметка

Вы хотите включить опцию IdentitiesOnly yes чтобы предотвратить использование идентификаторов по умолчанию. В противном случае, если у вас также есть идентификаторы, совпадающие с именами по умолчанию, они будут проверены первыми, потому что, в отличие от других параметров конфигурации (которые соблюдают "первый в выигрыше") IdentityFile Опция добавляет в список личностей, чтобы попробовать. См.: https://serverfault.com/questions/450796/how-could-i-stop-ssh-offering-a-wrong-key/450807

Источник

Настройте свой репозиторий, используя git config. Например:

git config --add --local core.sshCommand 'ssh -i ~/.ssh/<<<PATH_TO_SSH_KEY>>>'
Источник

Вы можете использовать переменную окружения git GIT_SSH_COMMAND, Запустите это в своем терминале под своим репозиторием git:

GIT_SSH_COMMAND='ssh -i ~/.ssh/your_private_key' git submodule update --init

замещать ~/.ssh/your_private_key с путем секретного ключа SSH, который вы хотите использовать. И вы можете изменить последующую команду git (в примере git submodule update --init) другим нравится git pull, git fetch, так далее.

Источник

Альтернативный подход, предложенный Марком Лонгэйром выше, заключается в использовании псевдонима, который будет запускать любую команду git на любом удаленном компьютере с альтернативным ключом SSH. Идея в основном состоит в том, чтобы переключать вашу личность SSH при запуске команд git.

Преимущества относительно подхода псевдонима хоста в другом ответе:

  • Будет работать с любыми командами или псевдонимами git, даже если вы не можете указать remote в явном виде.
  • Проще работать со многими репозиториями, потому что вам нужно настроить его только один раз для каждого клиентского компьютера, а не один раз для каждого репозитория на каждом клиентском компьютере.

Я использую несколько небольших скриптов и псевдоним Git admin, Таким образом, я могу сделать, например:

git admin push

Чтобы нажать на пульт по умолчанию, используя альтернативный ("admin") ключ SSH. Опять же, вы можете использовать любую команду (не только push) с этим псевдонимом. Вы могли бы даже сделать git admin clone ... клонировать репозиторий, доступ к которому у вас будет только при использовании вашего ключа "admin".

Шаг 1: Создайте альтернативные ключи SSH, при необходимости установите парольную фразу на случай, если вы делаете это на чужой машине.

Шаг 2: Создайте скрипт с именем "ssh-as.sh", который запускает материал, который использует SSH, но использует заданный ключ SSH, а не по умолчанию:

#!/bin/bash
exec ssh ${SSH_KEYFILE+-i "$SSH_KEYFILE"} "$@"

Шаг 3: Создайте скрипт с именем "git-as.sh", который запускает команды git с использованием данного ключа SSH.

#!/bin/bash
SSH_KEYFILE=$1 GIT_SSH=${BASH_SOURCE%/*}/ssh-as.sh exec git "${@:2}"

Шаг 4: Добавьте псевдоним (используя что-то подходящее для "PATH_TO_SCRIPTS_DIR" ниже):

# Run git commands as the SSH identity provided by the keyfile ~/.ssh/admin
git config --global alias.admin \!"PATH_TO_SCRIPTS_DIR/git-as.sh ~/.ssh/admin"

Более подробная информация по адресу: http://noamlewis.wordpress.com/2013/01/24/git-admin-an-alias-for-running-git-commands-as-a-privileged-ssh-identity/

Источник

Я собрал и протестировал с помощью github следующий подход, основанный на чтении других ответов, который сочетает в себе несколько методов:

  • правильный конфиг SSH
  • git перезапись URL

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

~/.ssh/config

# Personal GitHub
Host github.com
  HostName github.com
  User git
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/github_id_rsa

# Work GitHub
Host github-work
  HostName github.com
  User git
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/work_github_id_rsa

Host *
  IdentitiesOnly yes

~/.gitconfig

[user]
    name = My Name
    email = personal@personal.email

[includeIf "gitdir:~/dev/work/"]
    path = ~/dev/work/.gitconfig

[url "github-work:work-github-org/"]
    insteadOf = git@github.com:work-github-org/

~/dev/work/.gitconfig

[user]
    email = work@work.email

Пока вы храните все свои рабочие репозитории в ~/dev/work, а личные вещи где-то еще, git будет использовать правильный ключ SSH при выполнении запросов / клонирования / отправки на сервер, а также будет прикреплять правильный адрес электронной почты ко всем ваши коммиты.

Ссылки:

Источник

Чтобы использовать определенный ключ на лету:

      GIT_SSH_COMMAND='ssh -i $HOME/.ssh/id_ed25519 -o IdentitiesOnly=yes -F /dev/null' git push origin c13_training_network

Объяснение:

  • local ENV var перед выполнением нажатия
  • -i указывает ключ
  • -F заставляет пустую конфигурацию, чтобы ваш глобальный не перезаписывал эту временную команду
Источник

Начиная с git 2.10 и выше, также можно использовать параметр gitconfig sshCommand. Документы заявляют:

Если эта переменная установлена, git fetch и git push будут использовать указанную команду вместо ssh, когда им нужно подключиться к удаленной системе. Команда имеет ту же форму, что и переменная среды GIT_SSH_COMMAND, и переопределяется при установке переменной среды.

Пример использования: git config core.sshCommand "ssh -i ~/.ssh/[insert_your_keyname]

В некоторых случаях это не работает, потому что ssh_config переопределяет команду, в этом случае попробуйте ssh -i ~/.ssh/[insert_your_keyname] -F /dev/null не использовать ssh_config.

Источник

Одна из систем на основе 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. В файле введите:

Host your_host.com
     IdentityFile [absolute_path_to_your_.ssh]\id_rsa

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

Host github.com
     IdentityFile c:/users/[user_name]/.ssh/id_rsa

Путь также может быть записан в формате /c/users/[user_name]/....

Решение, предоставленное Джордано Скальцо, также великолепно. /questions/30016223/ne-udaetsya-nazhat-na-heroku-potomu-chto-otpechatok-klyucha/30016242#30016242

Источник

Если у вас уже есть конфигурация ssh по умолчанию, но вы хотите использовать другую для конкретного репозитория, это должно помочь:

      git config core.sshCommand "ssh -i ~/.ssh/github-personal -o IdentitiesOnly=yes -F /dev/null"
Источник

Одна возможность использовать ~/.ssh/config использовать Match ограничение вместо Hostограничение. В частностиMatch Execвызывает команду оболочки, чтобы решить, применять ли объявления или нет. В bash вы можете использовать следующую команду:

[ git@git.company.com:gitolite-admin = $(git config --get remote.origin.url)'' ]

Это использует bash [команда, чтобы проверить, равны ли две строки. В данном случае это проверка того, что строкаgit@git.company.com:gitolite-admin совпадает с выводом, полученным из $(git config --get remote.origin.url)'' команда.

Вы можете использовать любую другую команду, которая идентифицирует репозиторий, в котором находится оболочка. Для этого важно иметь$SHELL переменная, определенная для вашей оболочки, в моем случае /bin/bash. Тогда полный пример будет следующим~/.ssh/config:

Match Exec "[ git@git.company.com:gitolite-admin = $(git config --get remote.origin.url)'' ]"
  IdentityFile ~/.ssh/gitolite-admin
  IdentitiesOnly yes
  ForwardAgent no
  ForwardX11 no
  ForwardX11Trusted no

Match Exec "[ git@git.company.com:some_repo = $(git config --get remote.origin.url)'' ]"
  IdentityFile ~/.ssh/yourOwnPrivateKey
  IdentitiesOnly yes
  ForwardAgent no
  ForwardX11 no
  ForwardX11Trusted no

В этом примере я предположил, что ~/.ssh/yourOwnPrivateKey содержит ваш собственный закрытый ключ и ~/.ssh/gitolite-admin содержит закрытый ключ пользователя gitolite-admin. Я включилIdentitiesOnly yesдекларация, чтобы гарантировать, что серверу git предлагается только один ключ, упомянутый Mark Longair. Остальные объявления - это просто стандартные параметры ssh для git.

Вы можете добавить эту конфигурацию, если у вас несколько some_repoкоторые вы хотите использовать с разными ключами. Если у вас несколько репозиториев наgit@git.company.com и большинство из них используют ~/.ssh/yourOwnPrivateKeyимеет смысл включить этот ключ по умолчанию для хоста. В этом случае~/.ssh/config было бы:

Match Exec "[ git@git.company.com:gitolite-admin = $(git config --get remote.origin.url)'' ]"
  IdentityFile ~/.ssh/gitolite-admin
  IdentitiesOnly yes

Host git.company.com
  IdentityFile ~/.ssh/yourOwnPrivateKey
  IdentitiesOnly yes
  ForwardAgent no
  ForwardX11 no
  ForwardX11Trusted no

Обратите внимание, что порядок имеет значение, и Host git.company.com ограничение должно появиться после Match Exec один или несколько.

Источник

Как уже упоминал кто-то другой, core.sshCommand config можно использовать для переопределения ключа SSH и других параметров.

Вот пример, где у вас есть альтернативный ключ с именем ~/.ssh/workrsa и хотите использовать его для всех репозиториев, клонированных под ~/work.

  1. Создать новый .gitconfig файл под ~/work:
[core]
  sshCommand = "ssh -i ~/.ssh/workrsa"
  1. В вашей глобальной конфигурации git ~/.gitconfig, добавлять:
[includeIf "gitdir:~/work/"]
  path = ~/work/.gitconfig
Источник

Чтобы git понял, что он должен использовать другие ключи SSH, помимо изменения вашего файла конфигурации, как указано здесь: /questions/37190846/ukazhite-klyuch-ssh-dlya-git-push-dlya-dannogo-domena/37190880#37190880 вам также может потребоваться очистить и перезагрузить активный SSH идентичности.

На Mac сделайте следующее:

      ssh-add -D
ssh-add ~/.ssh/id_rsa_one_that_you_want_to_use_instead

Используя эти две команды и настраивая URL-адрес GIT в соответствии со строкой, определенной в Host файла ssh / config, должен позволить вам использовать разные ключи SSH для разных репозиториев.

Например для Host work.github.com использовать work.github.com как URL-адрес при клонировании вашего репозитория git@work.github.com:your/repository.git.

Источник

При использовании sit-версии Git для Windows строка файла идентификации в конфигурации ssh выглядит так:

IdentityFile /c/Users/Whoever/.ssh/id_rsa.alice

где /c для c:

Чтобы проверить, в Git's Bash сделать

cd ~/.ssh
pwd
Источник

Возможно, вам придется удалить (или закомментировать) конфигурацию хоста по умолчанию ssh / конфигурации

Источник

Примечание. Существует способ применить конфигурацию git, предложенную в предыдущем ответе , для каталогов, а не только на уровне репо.

В моем случае все проекты находились в каталоге, поэтому я обновил свой gitconfig следующим образом:

      # ~/.gitconfig
...

[includeIf "gitdir:~/work/**"]
  path = "~/work/.gitconfig"

      # ~/work/.gitconfig
[user]
  email = amr@work.com
  name = Amr Awad
  sshCommand = ssh -i ~/.ssh/work

и теперь все репозитории внутри ~/work/каталог использовать рабочий ключ ~/.ssh/workбез необходимости настраивать каждое репо отдельно.

Источник

Вы больше всего указали в файле конфигурации ключ ssh:

# Default GitHub user
Host one
 HostName gitlab.com
 User git
 PreferredAuthentications publickey
 IdentityFile ~/.ssh/key-one
 IdentitiesOnly yes

#two user
Host two
 HostName gitlab.com
 User git
 PreferredAuthentications publickey
 IdentityFile ~/.ssh/key-two
 IdentitiesOnly yes
Источник

вот простой подход:

-Из вашей локальной корневой папки git.

-Проверьте текущий тип метода аутентификации HTTPS или SSH вашего локального репозитория.

         git remote -v

 Example using HTTPS:
 origin  https://github.com/juantorres9/SQLite_crash_cours.git (fetch)
 origin  https://github.com/juantorres9/SQLite_crash_cours.git (push)
 Example using SSH:
 origin  git@github.com:juantorres9/SQLite_crash_cours.git (fetch)
 origin  git@github.com:juantorres9/SQLite_crash_cours.git (push)

-Установите метод аутентификации по вашему выбору, если он еще не установлен.

       For setting SSH
 git remote set-url origin git@github.com:USERNAME/REPOSITORY.git
 For setting HTTPS
 git remote set-url origin https://github.com/USERNAME/REPOSITORY.git

-Проверьте еще раз, если вы хотите перепроверить

       git remote -v

-Теперь вы можете использовать git push:fetch, используя настроенный вами метод.

      git push origin master

Примечание. И последнее, но не менее важное: проверьте обновленный официальный документ https://docs.github.com/en/get-started/getting-started-with-git/managing-remote-repositories.

Источник
Другие вопросы по тегам