На сайті GitHub є посилання ...

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

... і в ньому йдеться ...

Якщо ви вирішили не використовувати рекомендований метод HTTPS, ми можемо використовувати SSH ключі для встановлення безпечного зв’язку між вашим комп’ютером та GitHub. Наведені нижче кроки допоможуть вам створити ключ SSH, а потім додати відкритий ключ до вашого облікового запису GitHub.

Чому HTTPS є рекомендованим методом? Чи є якийсь недолік безпеки в методі SSH чи це повільніше? Я створив ключ SSH, щоб це зменшило будь-які проблеми з безпекою?

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.

Я припускаю, що 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, а не кешувати ім’я користувача та пароль у цій конфігурації інструментів.

Або ви цитуєте неправильно, або github має різні рекомендації на різних сторінках, або вони можуть дізнатися з часом і оновити своє відновлення.

Ми настійно рекомендуємо використовувати з'єднання SSH під час взаємодії з GitHub. SSH-ключі - це спосіб ідентифікувати надійні комп’ютери, не включаючи паролі. Наведені нижче кроки допоможуть вам створити ключ SSH, а потім додати відкритий ключ до вашого облікового запису GitHub.

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

Увімкнення 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

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

Редагувати:

Здається, що більше не потрібно мати доступ до запису до публічного репо, щоб використовувати URL-адресу SSH, що робить моє початкове пояснення недійсним.

ОРИГІНАЛ:

Очевидно, головна причина переваги HTTPS-URL-адрес полягає в тому, що URL-адреси SSH не працюватимуть із загальнодоступними репо-службами, якщо у вас немає доступу для запису до цього репо.

Використання URL-адрес SSH заохочується для розгортання на виробничих серверах, однак - імовірно, контекст тут - такі служби, як Heroku.

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

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

Може тому, що складніше вкрасти пароль у мозку, а потім викрасти файл ключа з вашого комп’ютера (принаймні, наскільки мені відомо, можливо, деякі речовини вже існують або методи, але це нескінченна дискусія)? І якщо ви захищаєте ключ ключем, ви знову використовуєте пароль, і виникають ті самі проблеми (але деякі можуть стверджувати, що вам доведеться зробити більше роботи, тому що вам потрібно отримати ключ, а потім зламати пароль).