Trên trang GitHub có một liên kết ...

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

... và nó tuyên bố ...

Nếu bạn đã quyết định không sử dụng phương pháp HTTPS được đề xuất, chúng tôi có thể sử dụng các khóa SSH để thiết lập kết nối an toàn giữa máy tính của bạn và GitHub. Các bước bên dưới sẽ hướng dẫn bạn cách tạo khóa SSH và sau đó thêm khóa chung vào tài khoản GitHub của bạn.

Tại sao HTTPS là phương pháp được đề xuất? Có một số lỗ hổng bảo mật trong phương thức SSH hay nó chậm hơn? Tôi đã tạo một khóa SSH, vì vậy điều đó có làm giảm bớt bất kỳ mối lo ngại nào về bảo mật không?

GitHub đã thay đổi đề xuất của họ nhiều lần ( ví dụ ).

Có vẻ như họ hiện đang đề xuất HTTPS vì đây là cách dễ nhất để thiết lập trên phạm vi rộng nhất của các mạng và nền tảng và bởi những người dùng mới đối với tất cả điều này.

Không có lỗ hổng cố hữu trong SSH (nếu có họ sẽ vô hiệu hóa nó) - trong các liên kết bên dưới, bạn sẽ thấy rằng họ vẫn cung cấp chi tiết về các kết nối SSH:

1. HTTPS ít có khả năng bị chặn bởi tường lửa.

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

   URL clone https: // có sẵn trên tất cả các kho lưu trữ, công khai và riêng tư. Các URL này hoạt động ở mọi nơi - ngay cả khi bạn đứng sau tường lửa hoặc proxy.

2. Kết nối HTTPS cho phép credential.helperlưu mật khẩu của bạn.

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

   Những điều cần biết: Trình trợ giúp thông tin chỉ hoạt động khi bạn sao chép URL repo HTTPS. Nếu bạn sử dụng URL repo SSH thay thế, các khóa SSH được sử dụng để xác thực. Mặc dù chúng tôi không khuyến nghị nhưng nếu bạn muốn sử dụng phương pháp này, hãy xem hướng dẫn này để được trợ giúp tạo và sử dụng khóa SSH.

Tôi cho rằng HTTPS được GitHub khuyên dùng vì nhiều lý do

1) Sử dụng đơn giản hơn từ mọi nơi vì bạn chỉ cần chi tiết tài khoản của mình (không yêu cầu khóa SSH)

2) HTTPS Là một cổng được mở trong tất cả các tường lửa. SSH không phải lúc nào cũng mở như một cổng để liên lạc với các mạng bên ngoài

Do đó, kho GitHub có thể truy cập phổ biến hơn bằng HTTPS so với SSH.

Theo quan điểm của tôi, các khóa SSH đáng để làm thêm một chút trong việc tạo ra chúng

1) Khóa SSH không cung cấp quyền truy cập vào tài khoản GitHub của bạn, vì vậy tài khoản của bạn không thể bị xâm nhập nếu khóa của bạn bị đánh cắp,

2) Sử dụng cụm từ khóa mạnh với khóa SSH sẽ hạn chế mọi hành vi lạm dụng, ngay cả khi khóa của bạn bị đánh cắp

Nếu thông tin đăng nhập tài khoản GitHub (tên người dùng / mật khẩu) của bạn bị đánh cắp, mật khẩu GitHub của bạn có thể được thay đổi để chặn bạn truy cập và tất cả các kho lưu trữ được chia sẻ của bạn có thể nhanh chóng bị xóa.

Nếu khóa riêng bị đánh cắp, ai đó có thể đẩy mạnh kho lưu trữ trống và xóa sạch tất cả lịch sử thay đổi cho từng kho lưu trữ mà bạn sở hữu, nhưng không thể thay đổi bất cứ điều gì trong tài khoản GitHub của bạn. Sẽ dễ dàng hơn nhiều để thử phục hồi từ vi phạm này khi bạn có quyền truy cập vào tài khoản GitHub của mình.

Sở thích của tôi là sử dụng SSH với khóa được bảo vệ bằng mật khẩu. Tôi có một khóa SSH khác nhau cho mỗi máy tính, vì vậy nếu máy đó bị đánh cắp hoặc khóa bị xâm phạm, tôi có thể nhanh chóng đăng nhập vào GitHub và xóa khóa đó để ngăn truy cập không mong muốn.

SSH có thể được tạo đường hầm qua HTTPS nếu mạng bạn đang chặn cổng SSH.

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

Nếu bạn sử dụng HTTPS, tôi khuyên bạn nên thêm xác thực hai yếu tố, để bảo vệ tài khoản cũng như kho lưu trữ của bạn.

Nếu bạn sử dụng HTTPS với một công cụ (ví dụ: trình chỉnh sửa), bạn nên sử dụng mã thông báo dành cho nhà phát triển từ tài khoản GitHub của mình thay vì lưu tên người dùng và mật khẩu trong cấu hình công cụ đó.

Hoặc bạn đang trích dẫn sai hoặc github có đề xuất khác nhau trên các trang khác nhau hoặc họ có thể học theo thời gian và cập nhật reco của họ.

Chúng tôi thực sự khuyên bạn nên sử dụng kết nối SSH khi tương tác với GitHub. Khóa SSH là một cách để xác định các máy tính đáng tin cậy, không liên quan đến mật khẩu. Các bước bên dưới sẽ hướng dẫn bạn cách tạo khóa SSH và sau đó thêm khóa chung vào tài khoản GitHub của bạn.

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

Kích hoạt kết nối SSH qua HTTPS nếu nó bị chặn bởi tường lửa

Kiểm tra xem SSH qua cổng HTTPS có khả thi hay không, hãy chạy lệnh SSH này:

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

Nếu điều đó làm việc, tuyệt vời! Nếu không, bạn có thể cần phải làm theo hướng dẫn xử lý sự cố của chúng tôi .

Nếu bạn có thể SSH vào git@ssh.github.comcổng 443 , bạn có thể ghi đè cài đặt SSH của mình để buộc mọi kết nối tới GitHub chạy qua máy chủ và cổng đó.

Để đặt phần này trong cấu hình ssh của bạn, hãy chỉnh sửa tệp tại ~/.ssh/configvà thêm phần này:

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

Bạn có thể kiểm tra xem cái này có hoạt động không bằng cách kết nối một lần nữa với GitHub:

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

Từ Xác thực đến GitHub / Sử dụng SSH qua cổng HTTPS

Xem thêm: chính thức Tôi nên sử dụng URL từ xa nào? trả lời trên help.github.com.

BIÊN TẬP:

Dường như không còn cần thiết phải có quyền truy cập ghi vào repo công khai để sử dụng URL SSH, khiến cho lời giải thích ban đầu của tôi không hợp lệ.

NGUYÊN:

Rõ ràng lý do chính để ủng hộ URL HTTPS là URL SSH sẽ không hoạt động với repo công khai nếu bạn không có quyền truy cập ghi vào repo đó.

Tuy nhiên, việc sử dụng URL SSH được khuyến khích triển khai cho các máy chủ sản xuất - có lẽ bối cảnh ở đây là các dịch vụ như Heroku.

Có thể lập luận rằng việc sử dụng khóa SSH để xác thực sẽ kém an toàn hơn vì chúng tôi có xu hướng thay đổi mật khẩu theo định kỳ hơn là tạo khóa SSH mới.

Các máy chủ giới hạn tuổi thọ mà chúng sẽ tôn trọng các khóa SSH được cung cấp có thể giúp người dùng thực hiện việc làm mới các khóa SSH theo định kỳ.

Có lẽ bởi vì việc đánh cắp mật khẩu từ não của bạn khó hơn sau đó đánh cắp một tệp chính từ máy tính của bạn (ít nhất là theo hiểu biết của tôi, có thể một số chất đã tồn tại hoặc phương pháp nhưng đây là một cuộc thảo luận vô tận)? Và nếu mật khẩu của bạn bảo vệ khóa, thì bạn đang sử dụng lại mật khẩu và các vấn đề tương tự phát sinh (nhưng một số người có thể cho rằng bạn phải làm nhiều việc hơn, vì bạn cần lấy khóa và sau đó bẻ khóa mật khẩu).