Mengapa GitHub merekomendasikan HTTPS melalui SSH?

334

Di situs GitHub ada tautan ...

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

... dan menyatakan ...

Jika Anda memutuskan untuk tidak menggunakan metode HTTPS yang disarankan, kami dapat menggunakan kunci SSH untuk membuat koneksi aman antara komputer Anda dan GitHub. Langkah-langkah di bawah ini akan memandu Anda menghasilkan kunci SSH dan kemudian menambahkan kunci publik ke akun GitHub Anda.

Mengapa HTTPS metode yang disarankan? Apakah ada semacam cacat keamanan dalam metode SSH atau lebih lambat? Saya membuat kunci SSH, jadi apakah itu akan mengurangi masalah keamanan?

git github ssh https John Livermore
sumber
39
Kurang konfigurasi berarti lebih mudah, mungkin. Selain itu, beberapa sistem operasi yang lebih rendah bahkan tidak memiliki klien SSH diinstal secara default.
katspaugh
45
Untuk pengguna mendatang yang menemukan utas ini: GitHub telah mengubah kebijakan mereka dan sekarang mengatakan "Kami sangat menyarankan menggunakan koneksi SSH saat berinteraksi dengan GitHub."
beardedlinuxgeek
9
@StevePomeroy, saya tidak berpikir pernyataan "sangat merekomendasikan" ada di lokasi itu.
Noel Abrahams
5
@BonsaiOak Dulu ada di halaman yang terhubung dengan Steve Pomeroy - web.archive.org/web/20140321204642/https://help.github.com/… - tetapi sepertinya mereka mengubahnya sejak saat itu.
beardedlinuxgeek
5
@ br3nt Benar. Mereka dulu tidak merekomendasikannya. Lalu mereka melakukannya. Lalu mereka tidak lagi. Itu sebabnya tautan saya ke halaman archive.org
beardedlinuxgeek

Jawaban:

192

GitHub telah mengubah rekomendasi mereka beberapa kali ( contoh ).

Tampaknya mereka saat ini merekomendasikan HTTPS karena ini adalah yang termudah untuk dibuat pada jangkauan jaringan dan platform terluas, dan oleh pengguna yang baru mengenal semua ini.

Tidak ada cacat bawaan pada SSH (jika ada mereka akan menonaktifkannya) - di tautan di bawah, Anda akan melihat bahwa mereka masih memberikan detail tentang koneksi SSH juga:

  1. HTTPS kecil kemungkinannya diblokir oleh firewall.

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

    Https: // URL klon tersedia di semua repositori, publik dan pribadi. URL ini berfungsi di mana-mana - bahkan jika Anda berada di belakang firewall atau proxy.

  2. Koneksi HTTPS memungkinkan credential.helperuntuk menyimpan kata sandi Anda.

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

    Baik untuk diketahui: Pembantu kredensial hanya berfungsi saat Anda mengkloning URL repo HTTPS. Jika Anda menggunakan URL repo SSH sebagai gantinya, kunci SSH digunakan untuk otentikasi. Meskipun kami tidak merekomendasikannya, jika Anda ingin menggunakan metode ini, lihat panduan ini untuk membantu menghasilkan dan menggunakan kunci SSH.

k107
sumber
52
Ah, jadi mereka merekomendasikan HTTPS hanya supaya mereka tidak perlu mendokumentasikan ssh-agent? Cukup adil. Terima kasih!
sarnold
74
@sarnold Ini mungkin lebih berkaitan dengan volume pertanyaan terkait ssh-agent dan manajemen kunci publik, dan jumlah firewall perusahaan yang memungkinkan HTTP / HTTPS keluar tetapi bukan SSH.
Todd A. Jacobs
7
Saya pikir https memudahkan orang untuk memulai karena Anda tidak harus melakukan seluruh bisnis kunci generate / copy / paste ssh. Juga dapat dipandang lebih aman dari perspektif Github karena penyerang yang mendapatkan kata sandi ssh Anda (atau menemukan terminal komputer yang Anda buka terbuka) masih harus mengetahui kata sandi Github Anda untuk mendorong apa pun.
k107
4
@ Kristi Jika penyerang menemukan terminal itu sebelum cache kata sandi kedaluwarsa, bukankah dia masih bisa mendorong bahkan jika dia tidak tahu kata sandinya? Pertanyaannya hampir sama jika Anda menggunakan ssh-agent, perbedaan yang jelas adalah Anda harus memasukkan kata sandi kunci ssh alih-alih kata sandi github Anda (dan sepertinya tidak ada pengaturan yang jelas untuk kedaluwarsa cache). Gagasan memasukkan kata sandi github alih-alih kata sandi kunci ssh tampaknya merupakan langkah mundur, meskipun kecil karena kekuatan kedua tombol tersebut memberi Anda AFAIK yang sama.
Halil Özgür
8
Saya pikir ini hampir seluruhnya tentang mengurangi volume permintaan dukungan yang mereka dapatkan. Saya kira Anda juga bisa berpendapat bahwa karena Anda harus memasukkan kata sandi Anda melalui HTTPS untuk mengakses situs web, Anda tidak dapat meningkatkan keamanan dengan menggunakan mekanisme otentikasi yang berbeda (kunci SSH), tetapi mungkin Anda meningkatkan permukaan serangan yang dapat menurunkan keamanan. Namun, baik HTTPS dan SSH harus cukup aman jika digunakan dengan benar.
Cartroo
52

Saya berasumsi HTTPS direkomendasikan oleh GitHub karena beberapa alasan

1) Lebih mudah digunakan dari mana saja karena Anda hanya memerlukan detail akun Anda (tidak perlu kunci SSH)

2) HTTPS Adalah port yang terbuka di semua firewall. SSH tidak selalu terbuka sebagai port untuk komunikasi ke jaringan eksternal

Repositori GitHub lebih mudah diakses secara universal menggunakan HTTPS daripada SSH.

Dalam pandangan saya kunci SSH sepadan dengan sedikit kerja ekstra dalam membuatnya

1) Kunci SSH tidak memberikan akses ke akun GitHub Anda, sehingga akun Anda tidak dapat dibajak jika kunci Anda dicuri,

2) Menggunakan frase kunci yang kuat dengan kunci SSH Anda membatasi penyalahgunaan, bahkan jika kunci Anda dicuri

Jika kredensial akun GitHub Anda (nama pengguna / kata sandi) dicuri, kata sandi GitHub Anda dapat diubah untuk memblokir Anda dari akses dan semua repositori yang Anda bagikan dapat dengan cepat dihapus.

Jika kunci pribadi dicuri, seseorang dapat melakukan push paksa repositori kosong dan menghapus semua riwayat perubahan untuk setiap repositori yang Anda miliki, tetapi tidak dapat mengubah apa pun di akun GitHub Anda. Akan jauh lebih mudah untuk mencoba pemulihan dari pelanggaran ini karena Anda memiliki akses ke akun GitHub Anda.

Preferensi saya adalah menggunakan SSH dengan kunci frasa sandi yang dilindungi. Saya memiliki kunci SSH yang berbeda untuk setiap komputer, jadi jika mesin itu dicuri atau dikompromikan, saya dapat dengan cepat masuk ke GitHub dan menghapus kunci itu untuk mencegah akses yang tidak diinginkan.

SSH dapat disalurkan melalui HTTPS jika jaringan Anda berada di blok port SSH.

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

Jika Anda menggunakan HTTPS, saya akan merekomendasikan untuk menambahkan otentikasi dua faktor, untuk melindungi akun Anda serta repositori Anda.

Jika Anda menggunakan HTTPS dengan alat (mis. Editor), Anda harus menggunakan token pengembang dari akun GitHub Anda alih-alih cache nama pengguna dan kata sandi dalam konfigurasi alat itu.

jr0cket
sumber
3
"walaupun jika seseorang memegang kunci pribadi Anda, mereka dapat melakukan push paksa repositori kosong dan menghapus riwayat perubahan Anda" - ya (dan akan mengerikan), tetapi keindahan basis kode yang didistribusikan memungkinkan kami untuk pulih dengan seseorang yang memiliki salinannya setidaknya.
Cameron
Saya tidak yakin menyatakan bahwa seseorang yang dapat memaksa mendorong adalah pembeda antara SSH dan HTTPS. Jika saya memiliki nama pengguna dan kata sandi Anda, saya juga bisa memaksa push.
Matt Canty
Jika Anda memiliki nama pengguna & kata sandi, Anda dapat menghapus semuanya (setelah mengubah kata sandi dan kontak email tentu saja). Tidak perlu melakukan force push individual pada setiap repositori jika Anda bisa menghapusnya.
jr0cket
Anda membandingkan kata sandi vs kunci ssh sementara koneksi https memerlukan token khusus.
Alexey Sh.
13

Entah Anda mengutip salah atau github memiliki rekomendasi berbeda pada halaman yang berbeda atau mereka dapat belajar dengan waktu dan memperbarui reco mereka.

Kami sangat menyarankan menggunakan koneksi SSH saat berinteraksi dengan GitHub. Kunci SSH adalah cara untuk mengidentifikasi komputer tepercaya, tanpa melibatkan kata sandi. Langkah-langkah di bawah ini akan memandu Anda menghasilkan kunci SSH dan kemudian menambahkan kunci publik ke akun GitHub Anda.

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

Sid Sarasvati
sumber
22
FWIW, halaman ini tidak lagi berisi teks "sangat disarankan" dikutip dalam jawaban ini.
Scott Isaacs
Masih menggunakan "disarankan" untuk HTTPS di tautan berikut: help.github.com/articles/which-remote-url-should-i-use/... "Kloning dengan URL HTTPS (disarankan)"
JBE
10

Mengaktifkan koneksi SSH melalui HTTPS jika diblokir oleh firewall

Uji apakah SSH melalui port HTTPS dimungkinkan, jalankan perintah SSH ini:

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

Jika itu berhasil, bagus! Jika tidak, Anda mungkin perlu mengikuti panduan pemecahan masalah kami .

Jika Anda dapat SSH ke [email protected]over port 443 , Anda dapat mengganti pengaturan SSH Anda untuk memaksa koneksi apa pun ke GitHub agar dijalankan melalui server dan port tersebut.

Untuk mengatur ini di konfigurasi ssh Anda, edit file di ~/.ssh/config, dan tambahkan bagian ini:

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

Anda dapat menguji apakah ini berfungsi dengan menghubungkan sekali lagi ke GitHub:

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

Dari Otentikasi ke GitHub / Menggunakan SSH melalui port HTTPS

mja
sumber
9

Lihat juga: resmi URL jarak jauh mana yang harus saya gunakan? jawab di help.github.com.

EDIT:

Tampaknya tidak perlu lagi memiliki akses tulis ke repo publik untuk menggunakan URL SSH, menjadikan penjelasan asli saya tidak valid.

ASLI:

Tampaknya alasan utama untuk menyukai URL HTTPS adalah bahwa URL SSH tidak akan berfungsi dengan repo publik jika Anda tidak memiliki akses tulis ke repo itu.

Penggunaan URL SSH dianjurkan untuk penyebaran ke server produksi, namun - mungkin konteksnya di sini adalah layanan seperti Heroku.

Mark Tye
sumber
1
"URL ini menyediakan akses ke repositori git melalui SSH. Untuk menggunakan URL ini, Anda harus memiliki akses tulis ke repositori publik atau akses apa pun ke repositori pribadi. URL ini tidak akan berfungsi dengan repositori publik yang Anda tidak punya akses tulis untuk " - INI TIDAK BENAR. Siapa pun dapat mengkloning repo publik dengan url SSH yang tidak memiliki akses tulis ke
Sam
1
@ Sam Mungkin ini tidak benar lagi, tetapi benar ketika saya menjawab pertanyaan itu. Saya telah mengedit jawaban saya untuk mencerminkan perubahan.
Mark Tye
Memang. Pertanyaan "Bagaimana GitHub merekomendasikan HTTPS melalui SSH" akan menjadi tidak masuk akal.
Mark Tye
0

Ada kemungkinan untuk berpendapat bahwa menggunakan kunci SSH untuk otentikasi kurang aman karena kami cenderung mengubah kata sandi kami lebih berkala daripada menghasilkan kunci SSH baru.

Server yang membatasi masa hidup yang akan mereka hormati diberikan kunci SSH dapat membantu memaksa pengguna terhadap praktik menyegarkan kunci SSH secara berkala.

benhorgen
sumber
Sekarang dianggap saran buruk untuk membuat pengguna mengubah kata sandi mereka secara berkala. Tampilan Pemerintah Inggris: ncsc.gov.uk/articles/problems-forcing-regular-password-expiry
nazerb
-3

Mungkin karena lebih sulit untuk mencuri kata sandi dari otak Anda kemudian mencuri file kunci dari komputer Anda (setidaknya setahu saya, mungkin beberapa zat sudah ada atau metode tetapi ini adalah diskusi yang tak terbatas)? Dan jika kata sandi Anda melindungi kunci, maka Anda menggunakan kata sandi lagi dan masalah yang sama muncul (tetapi beberapa orang mungkin berpendapat bahwa Anda harus melakukan lebih banyak pekerjaan, karena Anda perlu mendapatkan kunci dan kemudian memecahkan kata sandi).

Tadej
sumber