Github deploy keys: как мне разрешить несколько репозиториев для одной машины?

Ответ 1

Как только ключ был прикреплен к одному репо в качестве ключа развертывания, он не может быть используется на другом репо. Если вы используете эту ошибку при настройке а затем вам нужно будет изменить свой пульт и настроить ~/.ssh/config для использования несуществующего имени хоста github.com, который ssh сможет использовать для выбора правильного ключа развертывания ssh для вашего хранилище.

# first we remove the origin
$ git remote -v
origin  [email protected]:username/foo.git (fetch)
origin  [email protected]:username/foo.git (push)
$ git remote rm origin

# here we add a new origin using a host nickname called
# foo.github.com that we will reference with a Host stanza in our
# ~/.ssh/config to specify which key to use with which fake hostname.
$ git remote add origin [email protected]:username/foo.git
$ git remote -v
origin  [email protected]:username/foo.git (fetch)
origin  [email protected]:username/foo.git (push)

Создайте ключ развертывания для своего репозитория и назовите его разумно, как:

$ ssh-keygen -t rsa -f ~/.ssh/id_rsa-foo -C https://github.com/username/foo
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/username/.ssh/id_rsa-foo.
Your public key has been saved in /home/username/.ssh/id_rsa-foo.pub.
The key fingerprint is:
c0:ff:ee:34:24:11:5e:6d:7c:4c:b1:a0:de:ad:be:ef https://github.com/username/foo
The key randomart image is:
+--[ RSA 2048]----+
|  E   o..o.oo.   |
| M o o o .+CoW   |
|  + o = o. ..    |
| .   . +         |
|        S        |
|       o .       |
|        +        |
|       . o       |
|        ..o.     |
+-----------------+

Как только вы добавлен ключ развертывания вам нужно будет добавить следующую строфу в ваш файл ~/.ssh/config:

Host fake-hostname-foo.github.com
    Hostname github.com
    IdentityFile ~/.ssh/id_rsa-foo

Теперь вы можете протестировать его с помощью:

$ ssh -T [email protected]
Hi username! You've successfully authenticated, but GitHub
does not provide shell access.

Ответ 2

Самое простое найденное решение было описано здесь.

1) Введите эту команду (вы сделаете это для любого количества ключей, которые вам нужны):

ssh-keygen -t rsa -C "[email protected]"

2) При появлении запроса с указанным ниже типом введите уникальное имя (например, foo1_rsa). Файл будет создан в вашем текущем каталоге, и вам может потребоваться переместить его в .ssh, если вы хотите быть аккуратным:

Введите файл для сохранения ключа (/Users/you/.ssh/id_rsa): [Нажмите enter]

3) Обновите конфигурационный файл SSH:

vi ~/.ssh/config

Может быть пустым:

Host cheech github.com
Hostname github.com
IdentityFile ~/.ssh/foo1_rsa

Host chong github.com
Hostname github.com
IdentityFile ~/.ssh/foo2_rsa

Ответ 3

Развертывание ключа для github уникально... Вы должны сгенерировать новый ключ для другого репозитория. Просто запустите ssh-keygen снова

Смотрите документацию github для этого: https://help.github.com/articles/managing-deploy-keys

Ответ 4

Если вам удобно предоставлять rob доступ ко всем частным репозиториям в вашей учетной записи GitHub, вы можете удалить ключ в качестве ключа развертывания из cheech, а затем добавить его как SSH-ключ в свою учетную запись GitHub, как целое. Это дало бы rob доступ как к cheech, так и к chong.

Это не будет работать, если у вас есть другие репозитории в вашей учетной записи, которые вы не хотите получать rob.

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

Ответ 5

Управление несколькими ключами развертывания GitHub можно упростить с помощью моего крошечного модуля npm github-add-key. Он использует подход, описанный в этом отличный ответ, и все, что вам нужно, это

$github-add-key rob/chong

в локальном клонировании rob/chong и следуйте простому автоматическому процессу.

Ответ 6

Я знаю, что это 5+ лет, но там нет принятого ответа на этот популярный вопрос, поэтому вот то, что я считаю лучшим способом, рассматривающим чистоту и будущую читаемость:

ДОБАВИТЬ ПОЛЬЗОВАТЕЛЬ DEPLOY ДЛЯ ВАШЕЙ КОМАНДЫ

Шаг 1: Создайте новый адрес электронной почты в домене организации для нового пользователя развертывания. Что-то вроде [email protected]

Шаг 2: Используйте этот почтовый ящик для создания новой учетной записи GitHub (GitHub вызывает этих "пользователей компьютеров" ) дайте ему имя пользователя, например deploy-ExampleOrganisation, чтобы он был понятным.

Шаг 3. Создайте пользователя на своем сервере под названием "deploy" с помощью следующей команды:

useradd -d /home/deploy -m deploy

Создайте ключ SSH для развертывания @имя_сервера, не указывая никакую кодовую фразу и /home/deploy/.ssh/id_rsa в качестве местоположения файла:

ssh-keygen -t rsa -b 4096 -C "[email protected]"

Добавьте содержимое /home/deploy/.ssh/id_rsa.pub в качестве ключа SSH в вашей новой учетной записи deploy-ExampleOrganisation GitHub: выберите "Настройки" > "SSH" и "GPG" > "Новый SSH-ключ".

Шаг 4: Создайте команду в вашей организации, которая называется "Только для чтения", добавьте нового пользователя в команду и дайте команде прочитать доступ к любым репозициям, которые будут развернуты, (Если у вас нет учетной записи организации, вы все равно можете предоставить этому пользователю доступ к нескольким частным репозиториям)

Шаг 5: Добавьте свой собственный SSH-ключ для развертывания файла авторизированных ключей пользователя (/home/deploy/.ssh/authorized_keys), чтобы вы (или ваше развертывание script) могли войти в систему как развертывание при развертывании кода.

Boom! Что это... Теперь у вас есть чистый и самодокументированный поток.

P.S. Я пробовал ответить aculich на высокий голос, но он чувствовал себя грязным, возиться с фальшивыми именами хозяев, и я подумал: если я вернусь к этому через много лет, я собираюсь легко понять, что я сделал, чтобы создать все ключи и понять, как что SSH файл конфигурации делает эти смешные несуществующие удаленные адреса? Наверное, нет!

Преимущества метода развертывания пользователя по методу ложных имен узлов:

• Никаких хаков! Это стандартные учетные записи пользователей с четкими именами, доступ к репозиториям через имена реальных хостов.
• Меньше клавиш, плавающих вокруг.
• Если/когда вы переходите на дополнительные серверы, легко предоставить пользователю Deploy учетную запись на всех из них и просто добавив 1 новый ключ к своей учетной записи GitHub, ее учетная запись на новом сервере готова к развертыванию кода.
• Развернуть пользователя только с низким уровнем привилегий Доступ только для чтения только к репозиториям, указанным в команде, и ваши личные ключи SSH хранятся на сервере, поэтому, если какой-то неприятный человек действительно получает доступ к вашему серверу, они не могут навязать хау все ваши репозиции.
• Развертывание файлов конфигурации инструмента (например, Capistrano) не затуманивается, содержа их ошибочные имена поддельных хостов. (Это было, когда они начали распространяться за пределы сервера, что мне действительно стало неудобно с этим методом.)
• Если вы забыли, как, черт возьми, вы это сделали через несколько лет, владение файлом приведет вас к пользователю развертывания ls -la, ключ SSH приведет вас к имени учетной записи GitHub ssh -T [email protected] и, надеюсь, тогда вы полностью до скорости снова.
• И, наконец, это метод, рекомендованный GitHub.

Ответ 7

Вы также можете создать обертку ssh и передать ее как GIT_SSH. Преимущество этой опции состоит в том, что вам не нужно менять пульт git. fooobar.com/questions/94420/...

Ответ 8

Хотя идея Pimkin была великолепна, я не хотел устанавливать node только для этого, поэтому я создал нечто подобное в bash:

https://gist.github.com/blvz/8eeebacae11011c25fc79eff12f49ae9

Установка и использование:

curl https://gist.githubusercontent.com/blvz/8eeebacae11011c25fc79eff12f49ae9/raw/6f2f7f3709a0fe852d8a3a5bb125325e3ffbc7d8/gh-deploy-clone.sh > /usr/local/bin/gh-deploy-clone
chmod +x /usr/local/bin/gh-deploy-clone

gh-deploy-clone user/repo

# You can also give it a name, in case
# you have multiple deploy targets:

gh-deploy-clone user/repo staging