Предыдущая статья была посвящена "связке" git
+ gpg
. В этой же речь пойдёт о том, как при помощи протокола ssh удобно и безопасно работать с удалёнными git-репозиториями.
Кто этот ваш ssh?
SSH (Secure SHell) - это сетевой протокол, посредством которого два компьютера могут взаимодействовать и обмениваться данными. Важно, что данные при этом шифруются, поэтому протокол ssh считается безопасным.
С помощью ssh можно подключаться к удаленным серверам, выполнять на них команды, копировать и редактировать файлы.
Пакет openssh
входит в большинство дистрибутивов Linux по умолчанию. Если по какой-либо причине он отсутствует в вашей системе, вы можете установить его при помощи вашего пакетного менеджера.
Доступ к удалённым репозиториям
Зачем?
С 13 августа 2021 года GitHub убрал возможность использовать личный пароль для получения доступа к репозиториям по https из терминала. Вместо пароля от аккаунта на github.com при выполнении команд git clone
, git fetch
, git pull
, или git push
теперь необходимо указывать персональный токен доступа. Такое решение было принято с целью защиты пользователей и предотвращения использования злоумышленниками похищенных или взломанных паролей.
На мой взгляд, доступ к удалённым репозиториям по https (не важно - по паролю или по токену доступа) проигрывает в удобстве и гибкости доступу по ssh. При этом настройка подключения по ssh займёт у вас совсем немного времени - возможно, даже меньше, чем уйдёт на то, чтобы разобраться с токенами в GitHub. Именно поэтому я перешёл на использование ssh для всех удалённых репозиториев (расположенных не только на GitHub) даже раньше, чем GitHub перешёл на использование токенов вместо паролей.
Как?
Теперь рассмотрим конкретные шаги, которые необходимо выполнить, чтобы настроить работу с удалёнными репозиториями при помощи ssh. Я буду показывать все действия в терминале Linux.
Получаем ssh-ключи
Если у вас уже имеется пара ключей, которые вы хотите использовать для доступа к удалённым репозиториям, убедитесь, что файл с приватным ключом имеет права доступа rw-------
и при необходимости установите их командой:
chmod 600 ~/.ssh/personal_key
Если у вас ещё нет пары ssh-ключей (приватного и публичного), их необходимо сгенерировать при помощи утилиты ssh-keygen
.
ssh-keygen -t ed25519
Через флаг -t
задаём алгоритм, на основе которого будут сгенерированы ключи. GitHub, GitLab и Yandex рекомендуют использовать ed25519
.
Название файла, в который будет сохранён ключ, можно оставить дефолтным.
Далее по желанию можно задать пароль на генерируемый ключ. Если вы сделаете это, ssh будет требовать его при каждом использовании ключа. Чтобы не вводить пароль каждый раз, можно немного настроить ssh-agent - менеджер ключей для ssh.
После чего в терминал будет выведено "изображение" вашего ключа из ASCII-символов (красивое), а в папке ~/.ssh/
появятся два файла: id_ed25519
и id_ed25519.pub
с приватным и публичным ключами соответственно. Для удобства работы эти файлы можно переименовать:
mv ~/.ssh/id_ed25519 ~/.ssh/personal_key
mv ~/.ssh/id_ed25519.pub ~/.ssh/personal_key.pub
Настраиваем ssh config
Чтобы ssh мог автоматически использовать правильные ключи при работе с удалёнными репозиториями, необходимо задать некоторые настройки. А именно - добавить в файл ~/.ssh/config
следующие строки:
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/personal_key
IdentitiesOnly yes
где:
gihub.com
- url сервиса, с которым будем работать (указываем одинаковым вHost
иHostName
).~/.ssh/personal_key
- путь до файла с приватным ключом, который необходимо использовать для подключения.
Очевидно, аналогичные настройки можно произвести не только для GitHub'a, но и для иных сервисов (например, GitLab'a), добавив соответствующие строки в файл конфигурации.
Указываем публичный ключ на GitHub
Для того чтобы GitHub (или иной сервис) мог авторизовать ваше подключение, необходимо указать в настройках аккаунта публичный ssh-ключ, который вы будете использовать для доступа к репозиториям (также можно указать несколько ключей).
На github.com эта процедура делается следующим образом:
Переходим в "Settings" -> "SSH and GPG keys" (прямая ссылка).
Нажимаем "New SSH key".
В поле "Key" вставляем содержимое файла
personal_key.pub
(либоid_ed25519.pub
, если вы не переименовывали файлы).Нажимаем "Add SSH key".
Во всех остальных сервисах действия будут аналогичными.
При первом подключении по ssh необходимо будет добавить github.com (либо адрес того сервиса, который вы используете) в список доверенных хостов:
The authenticity of host 'github.com (140.82.121.4)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
Everything up-to-date
Готово! Теперь вы можете использовать ssh для доступа к удалённым репозиторям.
Имейте в виду, что при использовании протокола ssh пути до ваших удалённых репозиториев будет отличаться от путей, которые соответствовали протоколу https. Чтобы склонировать репозиторий с GitHub по ssh, вам нужно будет выбрать вкладку "ssh" в меню клонирования репозитория, после чего использовать указанный путь аналогично обычному "https-пути" (например, указать в качестве аргумента команды git clone
).
Как сменить адрес удалённого репозитория
Если у вас уже есть репозиторий, синхронизация которого с удалённым сервером происходила по протоколу https, а теперь вы хотите использовать ssh, вам необходимо будет сменить адрес удалённого репозитория, выполнив следующую команду в локальном репозитории:
git remote set-url origin git@serviceurl:username/reponame.git
где:
serviceurl
- url сервиса, на котором находится удалённый репозиторий (например,github.com
илиgitlab.com
).username
- ник владельца репозитория.reponame
- название репозитория.
Проверить, что изменения прошли корректно, можно путём выполнения команды
git remote -v
в локальном репозитории. Если в выводе содержатся строки вида:
origin git@serviceurl:username/reponame.git (fetch)
origin git@serviceurl:username/reponame.git (push)
с путями до вашего удалённого репозитория, значит, всё сделано правильно.
Полезные ссылки
Статья "Как работать с несколькими GitHub-аккаунтами на своей локальной машине"
GitHub docs: "Connecting to GitHub with SSH"
Выводы
Используйте протокол ssh для доступа к удалённым git-репозиториям. Это безопасно и удобно!
Комментарии (15)
z250227725
16.08.2023 14:30+2А почему в host и hostname нужно указывать одинаковое значение? А как настроить доступ к разным репозиториям GitHub с разными ключам? А зачем вы написали статью в которой информации меньше чем в справке GitHub по настройке подключения SSH?
Yu-Leo Автор
16.08.2023 14:30А почему в host и hostname нужно указывать одинаковое значение?
Hostname
- реальное имя хоста, на который мы обращаемся (github.com, например)Host
- в каком-то роде "псевдоним". Да, он может отличаться отHostname
, но тогда все URI-адреса, идентифицирующие удалённые репозитории, должны будут содержать его вместо реального адреса.Т.е. можно в конфиге задать:
Host myhost HostName github.com User git IdentityFile ~/.ssh/personal_key IdentitiesOnly yes
но тогда и удалённые репозитории будут иметь адреса вида
git@myhost:username/reponame.git
.Зачем это нужно, если для получения доступа используется один ключ, мне не понятно. В этом случае, на мой взгляд, логичнее задать в
Host
реальный адрес хоста, чтобы:Не создавать путаницу
При клонировании репозиториев, например, с GitHub использовать стандартные адреса вида
git@github.com:username/reponame.git
и не иметь проблем.
А как настроить доступ к разным репозиториям GitHub с разными ключам?
На практике пока не сталкивался с такой задачей.
Во-первых, этот вопрос рассмотрен в статье "How to Manage Multiple SSH Keys", перевод которой я указал в своей статье. А именно - через настройку git'а:
git config core.sshCommand 'ssh -i ~/.ssh/id_rsa_corp'
Во-вторых, предположу, что также можно при помощи упомянутых ранее настроек в ssh-конфиге:
Host host_1 HostName github.com User git IdentityFile ~/.ssh/key_1 IdentitiesOnly yes Host host_2 HostName github.com User git IdentityFile ~/.ssh/key_2 IdentitiesOnly yes
Первый репозиторий будет иметь адрес
git@host_1:user/repo_1.git
и к нему мы будем получать доступ при помощи первого ключа. Второй репозиторий будет иметь адресgit@host_2:user/repo_2.git
и к нему мы будем получать доступ при помощи второго ключа.А зачем вы написали статью в которой информации меньше чем в справке GitHub по настройке подключения SSH?
Потому что я хотел написать краткий и практико-ориентированный туториал по тому, как настроить ssh-подключение.
hipachka
16.08.2023 14:30-2А под каким пользователем вы рекомендуете ключи генерировать? Есть какой-то доступ к пользователю root, подскажите пожалуйста он подойдет?
Yu-Leo Автор
16.08.2023 14:30+2Рекомендую генерировать под своим пользователем. Не совсем понимаю, зачем в данном случае генерировать их с правами супер-пользователя (от пользователя
root
)hipachka
16.08.2023 14:30-2Для той аудитории для которой вы пишите скорей всего своим/обычным будет пользователь root. Ключи для root можно сгенерировать. Аргументированную рекомендацию неплохо было бы включить в тело статьи.
Yu-Leo Автор
16.08.2023 14:30+1Для той аудитории для которой вы пишите скорей всего своим/обычным будет пользователь root.
Почему?
В Linux, наоборот, не рекомендуется (раз , два, три) без надобности работать от имениroot
-пользователя. Для большинства своим/обычным пользователем наверняка будет как раз собственный пользователь, созданный при установке системы (или в процессе её использования), а неroot
.Можно ли сгенерировать ssh-ключи от root'а? Можно. Зачем?
iig
16.08.2023 14:30-2Зачем?
Потомушто ;)
Так то ключ от root и ключ от guest не отличаются ничем ;) Это просто файлы. Более того, если просто сгенерировать ключ - автоматически доступ никуда не настроится, даже к localhost.
hipachka
16.08.2023 14:30Вы вроде как сделали что-то вроде инструкции. В которой есть такой пункт "Если у вас ещё нет пары ssh-ключей". Вот добавьте туда рекомендацию о генерации этих самых ключей не под root. Я не могу вам сказать зачем и почему это было сделано, но иногда такое попадалось. Зачем добавить? Чтобы попадалось поменьше.
GSh13
16.08.2023 14:30Тема подписи коммитов ssh-ключом не раскрыта. Подозреваю что это как раз тема следующей статьи.
iig
16.08.2023 14:30https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits
Все уже написано до нас. Ждем видеоинструкцию.
take
Хабр медленно, но уверено превращается в УГ -- это первое. Давно тут не был.
Второе, )
Неплохо было бы указать почему все-таки ed25519 тип лучше rsa, наверное, как минимум потому, что он современнее, быстрее, надежнее и.. короче )
короткий путь к переименованию файла таков (бывает, что длинна пути к файлу это целое мучение, впрочем, вообще, принято экономить):
mv ~/.ssh/{id_ed25519,personal_key}
iig
бесспорно ;)
тема скорости ключа не раскрыта ;)
rsa с актуальной длиной взломают одновременно с запуском промышленного термоядерного реактора, лет через 20. А нет ли в выбранной эллиптической кривой уязвимостей - науке неизвестно ;)
его же не требуется зазубривать? ;)
Yu-Leo Автор
Спасибо за дополнение!
Про такой короткий способ переименования файлов, честно признаюсь, не знал. Спасибо