Git — это бесплатная распределенная система управления версиями с открытым исходным кодом, которая позволяет пользователям отслеживать изменения файлов.
Удаленные репозитории Git облегчают совместную работу над исходным кодом во время разработки программного обеспечения.
HTTPS и SSH — это два разных способа подключения к удаленному репозиторию GitHub через командную строку.
В этой статье вы узнаете о разнице между использованием SSH и HTTPS для Git и о том, как выбрать правильный метод аутентификации.
SSH или HTTPS для Git: в чем разница?
Базовой функциональностью SSH и HTTPS является шифрование данных, поскольку оба протокола являются безопасными криптографическими сетевыми протоколами.
Из-за своих функций безопасности многие серверы Git, включая GitHub и GitLab, используют SSH и HTTPS для защиты связи между клиентом и сервером.
Метод аутентификации зависит от того, какой удаленный URL-адрес вы выбираете HTTPS или SSH при клонировании репозитория Git, как показано на рисунке ниже:
HTTPS
HTTPS (Hyper Text Transfer Protocol Secure) — распространенный сетевой протокол, использующий шифрование данных SSL/TLS.
HTTPS проще настроить, чем SSH, он более распространен, но обеспечивает более низкий уровень безопасности данных, поскольку не использует криптографию с открытым ключом.
Git с HTTPS использует аутентификацию на основе токенов для установки соединений через порт 443 в режиме аутентификации пары Public/Private.
Порт 443 открыт почти во всех брандмауэрах, что не всегда верно для SSH.
Недостатком использования HTTPS является то, что каждое действие, такое как git fetch, git pull или git push, запрашивает ваше имя пользователя и пароль.
SSH
SSH (Secure Shell) — это протокол шифрования с открытым ключом, который гарантирует, что никто не сможет перехватить или изменить данные во время передачи.
Поскольку его сложнее настроить, он не так широко распространен, как HTTPS, но обеспечивает целостность и безопасность данных.
Однако брандмауэры в некоторых системах отказываются разрешать подключения SSH к порту по умолчанию, что может еще больше усложнить настройку.
Кроме того, в некоторых операционных системах клиенты SSH не установлены по умолчанию.
Зачем использовать HTTPS для Git?
Основная цель HTTPS — обеспечить безопасную передачу данных между клиентом и сервером.
HTTPS упрощает настройку Git, поскольку нет необходимости создавать ключи SSH для каждой машины, с которой вы хотите получить доступ к репозиторию.
Аутентификация выполняется с помощью токена личного доступа, который действует как уникальный пароль и позволяет пользователям дополнительно защитить свою учетную запись с помощью 2FA.
Преимущества использования HTTPS с Git:
Простая настройка.HTTPS легко настроить, требуется только URL-адрес репо и команда клонирования.
Доступность.HTTPS доступен во всех операционных системах и имеет очень мало ограничений брандмауэра.
Портативность.Получите доступ к репозиторию с любого компьютера, указав имя пользователя и пароль/токен.
Зачем использовать SSH для Git?
Целью установки SSH-соединения является шифрование данных, которыми обмениваются клиент и сервер.
Соединения SSH основаны на паре ключей — закрытый ключ на удаленном сервере и соответствующий открытый ключ в локальной системе.
Использование ключей SSH означает, что нет необходимости указывать имя пользователя и пароль для каждого действия, например, для отправки или получения изменений или подписания коммитов.
Преимущества использования SSH для Git:
Разовая установка.Для каждого действия SSH использует файл ключа на диске, который создается при клонировании репозитория.
Хотя настройка сложнее, чем HTTPS, это одноразовая операция.
Улучшенная безопасность.Ключи SSH более безопаснее, чем любой пароль или токен аутентификации, поэтому их практически невозможно взломать.
Сохранение времени.SSH не требует повторной аутентификации для каждого действия с хранилищем.Эта функция экономит время и делает SSH одной из главных причин выбора HTTPS.
Примечание. У некоторых пользователей могут возникнуть проблемы с подключением к Git через SSH, поскольку брандмауэр блокирует подключение к порту SSH по умолчанию.
Решите эту проблему в настройках SSH, чтобы соединения проходили через порт 443 (порт HTTPS по умолчанию, который должен быть открыт).
Для этого отредактируйте файл конфигурации ~/.ssh/config SSH и добавьте следующие строки:
Host github.com
Hostname ssh.github.com
Port 443
User git
Затем протестируйте новую конфигурацию, запустив:
$ ssh -T -p 443 git@ssh.github.com
Почему Git меняет свою рекомендацию?
Git несколько раз менял свою официальную документацию, чередуя рекомендацию между SSH и HTTPS.
В настоящее время нет рекомендаций для того или иного, но инструкции сосредоточены в основном на настройке SSH и устранении неполадок.
Git, вероятно, изменил свою рекомендацию с SSH, потому что HTTPS более доступен для всех.
Это самый простой способ настроить Git в самых разных сетях и платформах.
Заключение
В этой статье показаны преимущества использования HTTPS или SSH для Git.
Оба шифруют данные, пересылаемые между пользователем и удаленным хранилищем, при этом SSH является более безопасным вариантом, а HTTPS проще в использовании.
HTTPS – это HTTP поверх TLS. А TLS как раз использует шифрование передаваемых данных на базе ассиметричных ключей. И ключи эти, в большинстве случаев, настроены на стороне сервера. В некоторых случаях, для аутентификации клиентов на веб-сервере, могут быть настроены клиентские асимметричные пары, и выпущенные для этих пар сертификаты. Да на фаерволе достаточно отсавить открытым 443 порт как и для всего веб-сервиса.
Криптостойкость защифрованного канала между клиентом и сервером после TLS-handshake обеспечивается поддерживаемым набором криптоалгоритмов на сервере. Ну и если клиент в них умеет.
SSH так же может использовать для аутентификации ассиметричные пары ключей. Но он изначально создавался для защищенного подклчения и передачи команд и данных на серверва, где установлен SSH-сервер. Криптостойкость так же зависит от версий сервера и клиента и настраиваемого набора криптоалгоритмов для сеанса связи.
В статье авто описывает разницу в аутентификации клиента на таких службах системы контроля версий как Github, GitLab и др. И разница между ними такая:
Передаваемые данные в обоих случаях зашифрованы ассиметричными алгоритмами.
Но в случае работы по https сервер должен как-то аутентифицировать клиента. Мало подключиться к https эндпойнту – надо убедительно показать серверу кто ты есть. И поэтому после TLS-handshake – мы передаем серверу или токены или другие авторизационные данные. И наш коммит принимается или отклаоняется из-за неудачи авторизации.
В случае аутентификации по SSH, – мы предварительно сохраняем на сервере СКВ свой публичный ключ. А отправка данных на сервер – использует уже SSH транспорт для подключения. В этом случае аутентификация клиента происходит на основе его публичного ключа, сохраненного ранее. При таком подключении приходится на фаерволах открывать уже порт 22 или кастомный, изначально предназначенный для администрирования самого сервера. И открывать этот порт администраторы не спешат из-за возможного проникновения. SSH протокол за время сеанса использует как ассиметричное шифрование и алгоритмы обмена ключами, так и симметричное – для шифрования данных после выработанного в сеансе ключа.
HTTPS – это HTTP поверх TLS. А TLS как раз использует шифрование передаваемых данных на базе ассиметричных ключей. И ключи эти, в большинстве случаев, настроены на стороне сервера. В некоторых случаях, для аутентификации клиентов на веб-сервере, могут быть настроены клиентские асимметричные пары, и выпущенные для этих пар сертификаты. Да на фаерволе достаточно отсавить открытым 443 порт как и для всего веб-сервиса.
Криптостойкость защифрованного канала между клиентом и сервером после TLS-handshake обеспечивается поддерживаемым набором криптоалгоритмов на сервере. Ну и если клиент в них умеет.
SSH так же может использовать для аутентификации ассиметричные пары ключей. Но он изначально создавался для защищенного подклчения и передачи команд и данных на серверва, где установлен SSH-сервер. Криптостойкость так же зависит от версий сервера и клиента и настраиваемого набора криптоалгоритмов для сеанса связи.
В статье авто описывает разницу в аутентификации клиента на таких службах системы контроля версий как Github, GitLab и др. И разница между ними такая:
Локальный репозиторий мы получаем клонированием удаленного с сервера.
git clone https://github.com/repoX
или
gir clone git@github.com:repoX
Передаваемые данные в обоих случаях зашифрованы ассиметричными алгоритмами.
Но в случае работы по https сервер должен как-то аутентифицировать клиента. Мало подключиться к https эндпойнту – надо убедительно показать серверу кто ты есть. И поэтому после TLS-handshake – мы передаем серверу или токены или другие авторизационные данные. И наш коммит принимается или отклаоняется из-за неудачи авторизации.
В случае аутентификации по SSH, – мы предварительно сохраняем на сервере СКВ свой публичный ключ. А отправка данных на сервер – использует уже SSH транспорт для подключения. В этом случае аутентификация клиента происходит на основе его публичного ключа, сохраненного ранее. При таком подключении приходится на фаерволах открывать уже порт 22 или кастомный, изначально предназначенный для администрирования самого сервера. И открывать этот порт администраторы не спешат из-за возможного проникновения. SSH протокол за время сеанса использует как ассиметричное шифрование и алгоритмы обмена ключами, так и симметричное – для шифрования данных после выработанного в сеансе ключа.
Спасибо за обширное дополнение