Выкладка на сервер из приватного репозитория


Все правильные мальчики и девочки нынче пользуются ГитХабом для хранения своего кода. Вот и я такой же. Но я пошёл дальше и завёл себе немного приватных репозиториев для рабочих проектов, отказавшись от плясок с gitosis. При выкладке одного из них произошло странное…

Введение

Есть два способа выполнить clone или pull приватного репозитория на GitHub — либо через https, либо по ssh. Анонимного доступа по протоколу git не существует, что, собственно, и делает репозиторий закрытым. Сравните, как выглядит поле адреса для публичного и частного репозиториев:

Public RepoPrivate Repo

Естественно, я выбираю ssh, поскольку в этом протоколе возможна аутентификации без указания логина и пароля — аутентификация по ключу. Поскольку мне нужно просто «раскатать» репозиторий на сервере, то я воспользовался специально придуманной для таких случаев функцией «Deploy keys» — способом доступа к закрытому репозиторию на github.com только для чтения. Используя Deploy Keys, вы, например, сможете использовать post-commit хуки для автоматического вытягивания изменений при обновлении репозитория.

Коротко про Deploy Keys Процедура проста:

  • Создаём новую пару ключей (если их ещё нет на сервере), на вопрос ввода пароля просто нажимаем enter два раза — ключ-то только для чтения
  • Читаем публичный ключ и копируем полученных текст в github, в список Deploy keys нашего репозитория (Admin > Deploy keys > Add deploy key)
  • Клонируем репозиторий Для этого вводим в консоли:

    ssh-keygen cat ~/.ssh/id_rsa.pub git clone git@github.com:h4/private_repo.git

Если всё-всё сделано правильно и ssh на сервере тоже настроен правильно, то гит начнёт клонирование нашего закрытого репозитория.

Давай до свидания…

Однако, когда я попробовал провернуть это на хостинге TimeWeb, вместо бегущих цифр скаченных килобайт мне выплюнули Permission denied (publickey). Что произошло? Кроме очевидного, что доступ по публичному ключу почему-то не удался. Попробуем выяснить, запустив тестовое подключение с подробным выводом сообщений в консоль:

ssh -Tv git@github.

Вот тут-то меня ждало всё самое интересное (я вырезал большую часть вывода, оставив главное):

debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: identity file /root/.ssh/identity type -1
    debug1: Trying private key: /root/.ssh/identity
    debug1: No more authentication methods to try.

Перевожу на человеческий язык — в глобальном конфигурационном файле ssh админы Таймвеба переопределили стандартный путь к ключам авторизации на /root/.ssh/identity. Естественно у меня нет доступа к этому ключу на чтение и то же время ssh даже не пытается читать ключ в домашнем каталоге.

SSH, ты туда не ходи, ты сюда ходи

Для пресечения этого безобразия создаём файл ~/.ssh/config и пишем в него следующие строчки: Host * IdentityFile ~/.ssh/identity IdentityFile ~/.ssh/id_rsa IdentityFile ~/.ssh/id_dsa

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

ssh -T git@github.com

Нас радостно приветствует Октокэт, теперь можно клонировать репозиторий.

Hi h4/private_repo! You’ve successfully authenticated, but GitHub does not provide shell access.

Примечание

Вообще, с недавнего времени можно обойтись без ключей, авторизуясь по oAuth. Но мне ближе и проще ssh.