Предыдущая статья была посвящена "связке" git + gpg. В этой же речь пойдёт о том, как при помощи протокола ssh удобно и безопасно работать с удалёнными git-репозиториями.

Кто этот ваш ssh?

https://vk.com/wall-46453123_246691

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.

ssh-keygen.png

После чего в терминал будет выведено "изображение" вашего ключа из 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 эта процедура делается следующим образом:

  1. Переходим в "Settings" -> "SSH and GPG keys" (прямая ссылка).

  2. Нажимаем "New SSH key".

  3. В поле "Key" вставляем содержимое файла personal_key.pub (либо id_ed25519.pub, если вы не переименовывали файлы).

  4. Нажимаем "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).

github-https.png
github-ssh.png

Как сменить адрес удалённого репозитория

Если у вас уже есть репозиторий, синхронизация которого с удалённым сервером происходила по протоколу 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)

с путями до вашего удалённого репозитория, значит, всё сделано правильно.

Полезные ссылки

Выводы

Используйте протокол ssh для доступа к удалённым git-репозиториям. Это безопасно и удобно!

Комментарии (15)


  1. take
    16.08.2023 14:30
    +3

    Хабр медленно, но уверено превращается в УГ -- это первое. Давно тут не был.


    Второе, )

    Неплохо было бы указать почему все-таки ed25519 тип лучше rsa, наверное, как минимум потому, что он современнее, быстрее, надежнее и.. короче )

    короткий путь к переименованию файла таков (бывает, что длинна пути к файлу это целое мучение, впрочем, вообще, принято экономить):


    mv ~/.ssh/{id_ed25519,personal_key}


    1. iig
      16.08.2023 14:30
      +3

      современнее,

      бесспорно ;)

      быстрее,

      тема скорости ключа не раскрыта ;)

      надежнее

      rsa с актуальной длиной взломают одновременно с запуском промышленного термоядерного реактора, лет через 20. А нет ли в выбранной эллиптической кривой уязвимостей - науке неизвестно ;)

      и.. короче

      его же не требуется зазубривать? ;)


    1. Yu-Leo Автор
      16.08.2023 14:30
      +2

      Спасибо за дополнение!

      Про такой короткий способ переименования файлов, честно признаюсь, не знал. Спасибо


  1. z250227725
    16.08.2023 14:30
    +2

    А почему в host и hostname нужно указывать одинаковое значение? А как настроить доступ к разным репозиториям GitHub с разными ключам? А зачем вы написали статью в которой информации меньше чем в справке GitHub по настройке подключения SSH?


    1. 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 реальный адрес хоста, чтобы:

      1. Не создавать путаницу

      2. При клонировании репозиториев, например, с 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-подключение.


  1. hipachka
    16.08.2023 14:30
    -2

    А под каким пользователем вы рекомендуете ключи генерировать? Есть какой-то доступ к пользователю root, подскажите пожалуйста он подойдет?


    1. Yu-Leo Автор
      16.08.2023 14:30
      +2

      Рекомендую генерировать под своим пользователем. Не совсем понимаю, зачем в данном случае генерировать их с правами супер-пользователя (от пользователя root)


      1. hipachka
        16.08.2023 14:30
        -2

        Для той аудитории для которой вы пишите скорей всего своим/обычным будет пользователь root. Ключи для root можно сгенерировать. Аргументированную рекомендацию неплохо было бы включить в тело статьи.


        1. Yu-Leo Автор
          16.08.2023 14:30
          +1

          Для той аудитории для которой вы пишите скорей всего своим/обычным будет пользователь root.

          Почему?
          В Linux, наоборот, не рекомендуется (раз , два, три) без надобности работать от имени root-пользователя. Для большинства своим/обычным пользователем наверняка будет как раз собственный пользователь, созданный при установке системы (или в процессе её использования), а не root.

          Можно ли сгенерировать ssh-ключи от root'а? Можно. Зачем?


          1. iig
            16.08.2023 14:30
            -2

            Зачем?

            Потомушто ;)
            Так то ключ от root и ключ от guest не отличаются ничем ;) Это просто файлы. Более того, если просто сгенерировать ключ - автоматически доступ никуда не настроится, даже к localhost.


          1. hipachka
            16.08.2023 14:30

            Вы вроде как сделали что-то вроде инструкции. В которой есть такой пункт "Если у вас ещё нет пары ssh-ключей". Вот добавьте туда рекомендацию о генерации этих самых ключей не под root. Я не могу вам сказать зачем и почему это было сделано, но иногда такое попадалось. Зачем добавить? Чтобы попадалось поменьше.


            1. iig
              16.08.2023 14:30
              -1

              Зачем добавить? Чтобы попадалось поменьше.

              Лучше расскажите что произойдет плохого, если кто-то сгенерирует ключи из-под root.


              1. iig
                16.08.2023 14:30

                Понятно.. Вера в греховность root заставляет ставить минусики :) Штош, да пребудет с вами sudo :)


  1. GSh13
    16.08.2023 14:30

    Тема подписи коммитов ssh-ключом не раскрыта. Подозреваю что это как раз тема следующей статьи.


    1. iig
      16.08.2023 14:30

      https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits

      Все уже написано до нас. Ждем видеоинструкцию.