Почему GitHub рекомендует HTTPS над SSH?

На сайте GitHub есть ссылка...

https://help.github.com/articles/generating-ssh-keys

... и он утверждает...

Если вы решили не использовать рекомендуемый метод HTTPS, мы можем используйте SSH-ключи, чтобы установить безопасное соединение между вашим компьютером и GitHub. Следующие шаги помогут вам создать SSH и затем добавьте открытый ключ в свою учетную запись GitHub.

Почему HTTPS рекомендуемый метод? Есть ли какой-то недостаток безопасности в методе SSH или он медленнее? Я создал ключ SSH, так что это смягчит любые проблемы безопасности?

ОТВЕТЫ

Ответ 1

GitHub несколько раз менял свою рекомендацию (пример).

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

В SSH нет встроенного недостатка (если они были отключены) - в приведенных ниже ссылках вы увидите, что они по-прежнему предоставляют подробные сведения о соединениях SSH:

  • HTTPS с меньшей вероятностью блокируется брандмауэром.

    https://help.github.com/articles/which-remote-url-should-i-use/

    URL-адреса https://доступны для всех репозиториев, открытых и закрытых. Эти URL-адреса работают повсюду - даже если вы находитесь за брандмауэром или прокси.

  • Соединение HTTPS позволяет credential.helper кэшировать ваш пароль.

    https://help.github.com/articles/set-up-git

    Полезно знать: вспомогательный помощник работает только при клонировании HTTPS URL-адрес репо. Если вместо этого используется URL-адрес репозитория SSH, ключи SSH используются для аутентификация. Хотя мы не рекомендуем, если вы хотите использовать это метод, ознакомьтесь с этим руководством для получения справки и использования ключа SSH.

Ответ 2

Я предполагаю, что HTTPS рекомендуется GitHub по нескольким причинам

1) Его проще использовать из любой точки мира, поскольку вам нужны только данные вашей учетной записи (не требуются ключи SSH)

2) HTTPS - это порт, который открыт во всех брандмауэрах. SSH не всегда открыт как порт для связи с внешними сетями

Таким образом, репозиторий GitHub более универсально доступен с использованием HTTPS, чем SSH.

На мой взгляд, SSH-ключи стоят немного дополнительной работы по их созданию.

1) SSH-ключи не предоставляют доступ к вашей учетной записи GitHub, поэтому ваша учетная запись не может быть взломана, если ваш ключ украден,

2) Использование сильной ключевой фразы с вашим ключом SSH ограничивает любое злоупотребление, даже если ваш ключ украден

Если ваши учетные данные GitHub (имя пользователя/пароль) украдены, ваш пароль GitHub может быть изменен, чтобы заблокировать вам доступ, и все ваши общие репозитории могут быть быстро удалены.

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

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

SSH может быть туннелирован через HTTPS, если сеть, в которой вы находитесь, блокирует порт SSH.

https://help.github.com/articles/using-ssh-over-the-https-port/

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

Если вы используете HTTPS с инструментом (например, редактором), вы должны использовать токен разработчика из своей учетной записи GitHub, а не кэшировать имя пользователя и пароль в конфигурации этих инструментов.

Ответ 3

Либо вы указываете неправильно, либо github имеет разные рекомендации на разных страницах, или они могут учиться со временем и обновлять свои реко.

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

https://help.github.com/articles/generating-ssh-keys

Ответ 4

Также смотрите: официальный Какой удаленный URL я должен использовать? ответ на help.github.com.

РЕДАКТИРОВАТЬ:

Кажется, что больше нет необходимости иметь доступ для записи в публичный репозиторий, чтобы использовать URL-адрес SSH, что делает мое первоначальное объяснение недействительным.

ОРИГИНАЛ:

Очевидно, что основная причина предпочтения HTTPS-URL заключается в том, что SSH-URL не будет работать с публичным репо, если у вас нет прав на запись в это репо.

Однако использование SSH-URL рекомендуется для развертывания на производственных серверах - предположительно, контекст здесь относится к таким сервисам, как Heroku.

Ответ 5

Включение соединений SSH через HTTPS, если оно заблокировано брандмауэром

Проверьте, возможен ли SSH через порт HTTPS, выполните команду SSH:

$ ssh -T -p 443 [email protected]
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

Если это сработало, отлично! В противном случае вам может потребоваться следовать нашему руководству по устранению неполадок.

Если вы можете использовать SSH на [email protected] через порт 443, вы можете переопределить настройки SSH, чтобы заставить любое соединение с GitHub работать через этот сервер и порт.

Чтобы установить это в вашей конфигурации ssh, отредактируйте файл в ~/.ssh/config и добавьте этот раздел:

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

Вы можете проверить, что это работает, еще раз подключившись к GitHub:

$ ssh -T [email protected]
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

От аутентификации до GitHub/Использование SSH через порт HTTPS

Ответ 6

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

Серверы, которые ограничивают срок службы, за которые они будут соблюдать заданные ключи SSH, могут периодически заставлять пользователей периодически практиковать обновление SSH-ключей.

Ответ 7

Я согласен, что HTTPS - это порт, открытый на всех брандмауэрах, тогда как SSH может быть заблокирован некоторыми сетевыми брандмауэрами.

При использовании HTTPS каждый раз, когда вы выполняете git push, pull или clone, вы должны указывать свое имя пользователя и пароль, если они будут украдены, это будет представлять большой риск для всей вашей учетной записи GitHub.

git config credential.helper store хранит ваш пароль на диске, но сохраняет его в виде обычного текста.

С другой стороны, SSH требуется немного времени для генерации и установки закрытого и открытого ключа, но как только это будет сделано, вам никогда не придется предоставлять свои учетные данные, когда вы выполняете push, pull или клонирование, вы можете использовать все свои рабочие станции, имеющие SSH Настройка ключа для подключения к вашему хранилищу. И SSH-ключи более безопасны, чем хранение вашего пароля в виде простого текста!

Разница при использовании 2FA: когда вы включаете 2FA в своей учетной записи Github для добавления дополнительного уровня безопасности, вам необходимо создать токен личного доступа для HTTPS и вводить токен личного доступа всякий раз, когда вас просят ввести пароль. Хотя с SSH вам ничего не нужно делать, так как с SSH Github знает, что ваша личность и личный токен вообще не требуются!

http://jr0cket.co.uk/2016/05/ssh-or-https-that-is-the-github-question.html

Ответ 8

Я согласен, что HTTPS - это порт, открытый на всех брандмауэрах, тогда как SSH может быть заблокирован некоторыми сетевыми брандмауэрами.

При использовании HTTPS каждый раз, когда вы делаете git push, pull, clone или fetch, вы должны указывать свое имя пользователя и пароль, но не рекомендуется слишком часто использовать имя пользователя git и пароль git.

С другой стороны, SSH требуется немного времени для генерации и установки закрытого и открытого ключа, но как только это будет сделано, вам никогда не придется предоставлять свои учетные данные, когда вы делаете push, pull, клонирование или выборку, вы можете использовать все свои рабочие станции, имеющие Настройка ключа SSH для подключения к вашему хранилищу. И SSH-ключи более безопасны, чем хранение вашего пароля в виде простого текста!

Разница при использовании 2FA: когда вы включаете 2FA в своей учетной записи Github для добавления дополнительного уровня безопасности, вам необходимо создать токен личного доступа для HTTPS и вводить токен личного доступа всякий раз, когда вас просят ввести пароль. Хотя с SSH вам ничего не нужно делать, так как с SSH Github знает, что ваша личность и личный токен вообще не требуются!

https://help.github.com/en/articles/which-remote-url-should-i-use

Ответ 9

Может быть, потому что вам сложнее украсть пароль из вашего мозга, чтобы украсть файл ключа с вашего компьютера (по крайней мере, насколько мне известно, возможно, какие-то вещества уже существуют или методы, но это бесконечное обсуждение)? И если вы защищаете пароль от пароля, вы снова используете пароль и возникают те же проблемы (но некоторые могут утверждать, что вам нужно больше работать, потому что вам нужно получить ключ, а затем взломать пароль).