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

334

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

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

... и говорится ...

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

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

git github ssh https Джон Ливермор
источник
39
Меньше конфигурации, значит, проще. Кроме того, в некоторых операционных системах по умолчанию даже не установлены клиенты SSH.
katspaugh
45
Для будущих пользователей, которые найдут эту тему: GitHub изменил свою политику и теперь говорит: «Мы настоятельно рекомендуем использовать SSH-соединение при взаимодействии с GitHub».
Beardedlinuxgeek
9
@ StevePomeroy, я не думаю, что утверждение «настоятельно рекомендую» существует в этом месте.
Ноэль Абрахамс
5
@BonsaiOak Раньше он был на странице, на которую ссылался Стив Померой - web.archive.org/web/20140321204642/https://help.github.com/… - но похоже, что они изменили его с тех пор.
Beardedlinuxgeek
5
@ br3nt Правильно. Они раньше не рекомендовали это. Затем они сделали. Тогда они не снова. Вот почему моя ссылка на страницу archive.org
beardedlinuxgeek

Ответы:

192

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

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

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

  1. HTTPS менее вероятно будет заблокирован брандмауэром.

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

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

  2. HTTPS-соединение позволяет credential.helperкешировать ваш пароль.

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

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

K107
источник
52
Ах, они рекомендуют HTTPS просто, чтобы не документировать ssh-agent? Справедливо. Спасибо!
sarnold
74
@sarnold Вероятно, это больше связано с объемом вопросов, связанных с ssh-agent и управлением открытым ключом, а также с количеством корпоративных брандмауэров, которые разрешают исходящий HTTP / HTTPS, но не SSH.
Тодд А. Джейкобс
7
Я думаю, что https облегчает людям начало работы, так как вам не нужно заниматься бизнесом генерации / копирования / вставки ключей ssh. Кроме того, его можно рассматривать как более безопасный с точки зрения Github, поскольку злоумышленник, получивший ваш пароль ssh (или обнаруживший компьютерный терминал, который вы оставили открытым), все равно должен знать ваш пароль Github, чтобы что-то выдвинуть.
k107
4
@kristi Если злоумышленник обнаружит этот терминал до истечения срока действия кэша паролей, не сможет ли он все же нажать, даже если не знает пароль? Вопрос примерно такой же, если вы используете ssh-agent, очевидное отличие состоит в том, что вам нужно вводить пароль ключа ssh вместо пароля github (и, похоже, нет очевидных настроек для истечения срока действия кэша). Идея ввести пароль github вместо пароля ssh-ключа кажется шагом назад, хотя и небольшим, поскольку мощность, которую дают эти два ключа, примерно одинакова для AFAIK.
Халил Озгюр
8
Я думаю, что это почти полностью связано с уменьшением объема запросов поддержки, которые они получают. Я полагаю, вы могли бы также утверждать, что, поскольку вы все равно должны вводить свой пароль через HTTPS для доступа к веб-сайту, вы не можете повысить безопасность, используя другой механизм аутентификации (ключи SSH), но, возможно, вы увеличиваете поверхность атаки, которая может снизить безопасность. Тем не менее, HTTPS и SSH должны быть надлежащим образом защищены при правильном использовании.
Cartroo
52

Я предполагаю, что 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, а не кэшировать имя пользователя и пароль в конфигурации этих инструментов.

jr0cket
источник
3
«хотя, если кто-то завладеет вашим личным ключом, он может принудительно вытолкнуть пустой репозиторий и стереть вашу историю изменений» - да (и это было бы ужасно), но красота распределенных кодовых баз позволяет нам восстановиться с кем-то, кто имеет копию по крайней мере.
Кэмерон
Я не уверен, утверждая, что кто-то, способный к принудительному принудительному запуску, является дифференциатором между SSH и HTTPS. Если бы у меня были ваши имя пользователя и пароль, я мог бы в равной степени принудительно нажать.
Мэтт Канти
Если у вас есть имя пользователя и пароль, вы можете удалить все (после изменения пароля и адреса электронной почты, конечно). Нет необходимости делать отдельные принудительные нажатия на каждый репозиторий, если вы можете просто удалить их.
jr0cket
Вы сравниваете пароль с ключом ssh, в то время как для соединения https требуется специальный токен.
Алексей Ш.
13

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

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

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

Сид Сарасвати
источник
22
FWIW, эта страница больше не содержит текст «настоятельно рекомендую», цитируемый в этом ответе.
Скотт Айзекс
Все еще используется «рекомендуется» для HTTPS по следующей ссылке: help.github.com/articles/which-remote-url-should-i-use/… «Клонирование с URL-адресами HTTPS (рекомендуется)»
JBE
10

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

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

$ ssh -T -p 443 git@ssh.github.com
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

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

Если вы можете использовать SSH git@ssh.github.comчерез порт 443 , вы можете переопределить настройки SSH, чтобы заставить любое соединение с GitHub работать через этот сервер и порт.

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

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

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

$ ssh -T git@github.com
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

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

мя
источник
9

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

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

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

ОРИГИНАЛ:

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

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

Марк Тай
источник
1
«Эти URL-адреса предоставляют доступ к репозиторию git через SSH. Чтобы использовать эти URL-адреса, у вас должен быть доступ на запись к общедоступному репозиторию или любой доступ к частному репозиторию. Эти URL-адреса не будут работать с общедоступным репозиторием, к которому у вас нет прав на запись. " - ЭТО НЕПРАВДА. Любой может клонировать публичное репо с URL-адресом SSH, к которому у них нет прав на запись
Сэм
1
@ Сэм. Возможно, это уже не так, но было правдой, когда я ответил на вопрос. Я отредактировал свой ответ, чтобы отразить изменение.
Марк Тай
На самом деле. Вопрос «Как GitHub рекомендует HTTPS поверх SSH» был бы бессмысленным.
Марк Тай
0

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

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

benhorgen
источник
Сейчас считается плохим советом, чтобы пользователи периодически меняли свои пароли. Представления
nazerb
-3

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

Tadej
источник