Поиск по сайту:

Должны ли вы использовать HTTPS или SSH для Git?

При подключении к удаленным репозиториям Git, таким как Github, у вас обычно есть два варианта подключения — HTTPS или SSH. У обоих есть свое применение, и, хотя SSH обычно считается более безопасным, вопрос немного сложнее.

Какая разница?

Метод аутентификации, который вы используете для подключения к репозиторию Git, зависит от URL-адреса, с которым настроен ваш пульт. Формат URL-адреса по умолчанию, который использует Github, — это HTTPS, который обменивается данными напрямую через веб-протокол:

https://github.com/user/RepoName.git

Однако вы также можете использовать SSH. Хотя вы не открываете интерактивную оболочку и не выполняете команды, это все тот же формат, как если бы вы подключались к обычному серверу Linux с поддержкой SSH:

user@ipaddress:folder/file

В Github и большинстве сервисов вы подключаетесь к пользователю git и получаете доступ к конечной точке .git в виде файла в папке с вашим именем пользователя.

git@github.com:user/RepoName.git

Зачем использовать HTTPS?

Итак, какой из них вы должны использовать? Хотя SSH обычно считается более безопасным, для базового использования Github вполне приемлема HTTPS-аутентификация с паролем. Фактически, сам Github по умолчанию рекомендует большинству людей использовать HTTPS.

Однако это не так просто, как раньше: с августа 2021 года Github отключил использование пароля вашей учетной записи для аутентификации. Вам нужно будет создать токен личного доступа, который действует как второй пароль, но является уникальным и может иметь определенные разрешения. Это также позволяет вам без проблем использовать 2FA в своей учетной записи.

HTTPS имеет множество преимуществ:

  • HTTPS проще. Для большинства служб, кроме Github, вам просто нужно ввести свое имя пользователя и пароль, и вы сможете отправлять и получать код.
  • Вам не нужно манипулировать несколькими ключами SSH, чтобы использовать несколько устройств.
  • Порт 443, который использует HTTPS, открыт практически в любом брандмауэре, имеющем доступ в Интернет. Это не всегда так для SSH.

Основным недостатком для большинства людей является то, что вы должны вводить свой пароль/токен Git каждый раз, когда вы нажимаете. Хотя он добавляется в кеш, он не настроен на постоянное кеширование (хотя это можно изменить). С ключами SSH он просто использует файл ключа на диске каждый раз.

Зачем использовать SSH?

Это заблуждение, что HTTPS как протокол значительно менее безопасен, чем SSH. Оба обеспечат вам безопасное соединение, защищенное от атак «человек посередине» (MITM). Оба протокола будут выполнять свою работу одинаково, пока основные ключи защищены. Оба в любом случае будут использовать аутентификацию на основе открытого ключа, хотя HTTPS с Git отправит ваш пароль по сети. И оба протокола можно настроить для использования многофакторной аутентификации (MFA/2FA), хотя с Github проще использовать MFA в вашей учетной записи, если вы используете ключи SSH.

Где SSH берет на себя инициативу, так это в факторе аутентификации — ключе. Одна только его длина затрудняет случайную утечку, а из-за того, что он громоздкий и уникальный, он, как правило, более безопасен. Единственным недостатком является то, что он хранится в виде доступного пользователю файла на вашем жестком диске, а не в вашей голове, но, учитывая, насколько плохи люди в вопросах безопасности, возможно, так будет лучше.

Кроме того, он не подвержен утечке данных. Он гарантированно не будет повторно использован, но он также никогда не хранится на чужом сервере. Поскольку вы предоставляете Github только свой открытый ключ и используете свой закрытый ключ на своей стороне для выполнения задачи аутентификации, нет риска, что он будет раскрыт или даже когда-либо будет отправлен по сети.

У SSH много недостатков, но их можно смягчить, если вы знаете, что делаете:

  • Для настройки вашей учетной записи Github для использования вашего ключа SSH требуется всего несколько команд и щелчков в их настройках.
  • Управлять несколькими ключами на одном компьютере непросто, но это не так сложно настроить, настроив хост-файл SSH и удаленные устройства Git.
  • Перенос ключей на другие машины возможен, но, поскольку у вас может быть несколько ключей SSH, в этом нет необходимости.

SSH можно даже туннелировать через HTTPS при доступе к Github, используя имя хоста ssh.github.com в конфигурации SSH. Хотя это может быть не так для всех сервисов Git, это хороший плюс для большого:

Host github.com
  Hostname ssh.github.com
  Port 443

Ключи SSH также можно связать вместе с помощью переадресации агента SSH, что позволяет вам подключаться к удаленному серверу, а затем использовать ключ SSH на клиентском компьютере для аутентификации. Удаленный сервер действует как посредник, не зная о вашем ключе SSH.

Что следует использовать?

Вопрос в том, стоит ли с этим заморачиваться? Если у вас есть опыт работы с командной строкой, не так уж сложно просто использовать ключи, и большинство людей все равно будут это делать просто потому, что проще один раз настроить и больше никогда не вводить пароль. Он также лучше работает с 2FA, который, вероятно, должен использовать большинство учетных записей Github с высоким уровнем безопасности.

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