Na stronie GitHub znajduje się link ...

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

... i stwierdza ...

Jeśli zdecydujesz się nie używać zalecanej metody HTTPS, możemy użyć kluczy SSH w celu ustanowienia bezpiecznego połączenia między komputerem a GitHub. Poniższe kroki przeprowadzą Cię przez proces generowania klucza SSH, a następnie dodawania klucza publicznego do konta GitHub.

Dlaczego HTTPS jest zalecaną metodą? Czy jest jakaś luka w zabezpieczeniach w metodzie SSH, czy jest ona wolniejsza? Utworzyłem klucz SSH, więc czy złagodziłoby to jakiekolwiek obawy związane z bezpieczeństwem?

GitHub kilkakrotnie zmieniał swoje rekomendacje ( przykład ).

Wygląda na to, że obecnie zalecają HTTPS, ponieważ najłatwiej jest go skonfigurować w najszerszym zakresie sieci i platform oraz dla użytkowników, którzy są nowi w tym wszystkim.

W SSH nie ma nieodłącznej wady (gdyby ją wyłączono) - w poniższych linkach zobaczysz, że nadal zawierają szczegółowe informacje o połączeniach SSH:

1. Jest mniej prawdopodobne, że HTTPS zostanie zablokowany przez zaporę ogniową.

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

   Klonowane adresy URL https: // są dostępne we wszystkich repozytoriach, publicznych i prywatnych. Te adresy URL działają wszędzie - nawet jeśli jesteś za zaporą ogniową lub serwerem proxy.

2. Połączenie HTTPS umożliwia credential.helperbuforowanie hasła.

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

   Warto wiedzieć: pomocnik poświadczeń działa tylko po sklonowaniu adresu URL repozytorium HTTPS. Jeśli zamiast tego użyjesz adresu URL repozytorium SSH, klucze SSH są używane do uwierzytelniania. Chociaż nie zalecamy tego, jeśli chcesz skorzystać z tej metody, zapoznaj się z tym przewodnikiem, aby uzyskać pomoc w generowaniu i używaniu klucza SSH.

Zakładam, że GitHub zaleca HTTPS z kilku powodów

1) Łatwiej jest korzystać z dowolnego miejsca, ponieważ potrzebujesz tylko danych konta (nie wymaga kluczy SSH)

2) HTTPS Jest portem otwartym we wszystkich zaporach ogniowych. SSH nie zawsze jest otwarty jako port do komunikacji z sieciami zewnętrznymi

Repozytorium GitHub jest zatem bardziej powszechnie dostępne przy użyciu HTTPS niż SSH.

Moim zdaniem klucze SSH są warte trochę więcej pracy przy ich tworzeniu

1) Klucze SSH nie zapewniają dostępu do konta GitHub, więc nie można przejąć konta, jeśli klucz zostanie skradziony,

2) Użycie silnego hasła z kluczem SSH ogranicza wszelkie niewłaściwe użycie, nawet jeśli klucz zostanie skradziony

Jeśli dane logowania do konta GitHub (nazwa użytkownika / hasło) zostaną skradzione, hasło GitHub można zmienić, aby zablokować dostęp, a wszystkie udostępnione repozytoria można szybko usunąć.

Jeśli klucz prywatny zostanie skradziony, ktoś może wymusić wypchnięcie pustego repozytorium i wyczyścić całą historię zmian dla każdego repozytorium, które posiadasz, ale nie może niczego zmienić na Twoim koncie GitHub. O wiele łatwiej będzie spróbować odzyskać dane po tym naruszeniu dostępu do konta GitHub.

Preferuję używanie SSH z kluczem chronionym hasłem. Mam inny klucz SSH dla każdego komputera, więc jeśli ten komputer zostanie skradziony lub przejęty, mogę szybko zalogować się do GitHub i usunąć ten klucz, aby zapobiec niechcianemu dostępowi.

SSH można tunelować przez HTTPS, jeśli sieć, w której się znajdujesz, blokuje port SSH.

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

Jeśli używasz HTTPS, zalecam dodanie uwierzytelniania dwuskładnikowego, aby chronić twoje konto, a także repozytoria.

Jeśli używasz HTTPS z narzędziem (np. Edytorem), powinieneś użyć tokena programisty z konta GitHub zamiast buforować nazwę użytkownika i hasło w konfiguracji tego narzędzia.

Albo źle podajesz, albo github ma inne zalecenia na różnych stronach lub mogą się nauczyć z czasem i zaktualizować swoje reco.

Zdecydowanie zalecamy używanie połączenia SSH podczas interakcji z GitHub. Klucze SSH to sposób na identyfikację zaufanych komputerów, bez angażowania haseł. Poniższe kroki przeprowadzą Cię przez proces generowania klucza SSH, a następnie dodawania klucza publicznego do konta GitHub.

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

Włączanie połączeń SSH przez HTTPS, jeśli jest on blokowany przez zaporę

Sprawdź, czy SSH przez port HTTPS jest możliwy, uruchom następującą komendę SSH:

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

Jeśli to zadziałało, świetnie! Jeśli nie, może być konieczne skorzystanie z naszego przewodnika rozwiązywania problemów .

Jeśli możesz połączyć się z SSH [email protected]przez port 443 , możesz zastąpić ustawienia SSH, aby zmusić dowolne połączenie z GitHub do uruchomienia przez ten serwer i port.

Aby ustawić to w konfiguracji ssh, edytuj plik o ~/.ssh/configi dodaj tę sekcję:

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

Możesz sprawdzić, czy to działa, ponownie łącząc się z GitHub:

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

Od uwierzytelniania do GitHub / Korzystanie z SSH przez port HTTPS

Zobacz także: oficjalny Jakiego zdalnego adresu URL powinienem użyć? odpowiedz na help.github.com.

EDYTOWAĆ:

Wydaje się, że nie trzeba już mieć dostępu do zapisu w publicznym repozytorium, aby użyć adresu URL SSH, co powoduje, że moje oryginalne wyjaśnienie jest nieprawidłowe.

ORYGINALNY:

Najwyraźniej głównym powodem faworyzowania adresów URL HTTPS jest to, że adresy URL SSH nie będą działać z publicznym repozytorium, jeśli nie masz dostępu do zapisu do tego repozytorium.

Jednak użycie adresów URL SSH jest zalecane do wdrażania na serwerach produkcyjnych - przypuszczalnie kontekstem tutaj są usługi takie jak Heroku.

Można argumentować, że używanie klucza SSH do uwierzytelnienia jest mniej bezpieczne, ponieważ zwykle zmieniamy hasło częściej niż generujemy nowe klucze SSH.

Serwery, które ograniczają żywotność, dla której będą honorować dane klucze SSH, mogą pomóc zmusić użytkowników do praktyki okresowego odświeżania kluczy SSH.

Może dlatego, że trudniej jest ukraść hasło z mózgu niż ukraść plik klucza z komputera (przynajmniej o ile wiem, może niektóre substancje już istnieją lub metody, ale jest to nieskończona dyskusja)? A jeśli chronisz klucz hasłem, ponownie używasz hasła i pojawiają się te same problemy (ale niektórzy mogą argumentować, że musisz wykonać więcej pracy, ponieważ musisz zdobyć klucz, a następnie złamać hasło).