Menggunakan kunci penerapan yang sama untuk beberapa proyek github

94

Github tidak mengizinkan kunci penerapan ssh yang sama digunakan untuk lebih dari satu proyek, yang akan sangat berguna dalam beberapa kasus (misalnya, server CI yang menangani proyek dengan sub-modul pribadi). Saya telah melihat berbagai utas yang tampaknya mengatakan bahwa batasan ini ada karena 'alasan keamanan', tetapi saya belum melihat penjelasan yang meyakinkan tentang risiko apa yang akan meningkat.

Perhatikan bahwa fakta bahwa Github tidak mengizinkan kunci Tingkat Akun digunakan kembali masuk akal (dua pengguna tidak boleh berbagi kunci). Hanya batasan pada Deploy Keys yang saya pertanyakan.

Dan untuk memperjelas, saya tidak mencari solusi (buat pengguna dummy, gunakan banyak kunci, ...), tetapi hanya untuk penjelasan yang masuk akal untuk batasan pada Deploy Keys ini.

Utas terkait:

git github ssh David Ebbo
sumber
Karena tidak ada cara yang lebih baik untuk membuat pengguna penerapan khusus yang kami beri akses hanya-baca ke repositori. Hasil akhirnya adalah sama.
Datageek
Jawaban bagus di sini: stackoverflow.com/questions/11656134/…
apple16

Jawaban:

22

Satu-satunya alasan, yang diilustrasikan oleh solusi yang Anda rujuk (membuat satu pengguna "build", atau berbagi yang sama id_rsa.REPONAME.pubper repo) adalah:

hindari berbagi kunci publik / pribadi untuk pengguna yang berbeda

Meskipun itu tidak akan terjadi dalam situasi Anda (membangun beberapa proyek), mengizinkan untuk menggunakan kembali kunci ssh yang sama akan membuka kemungkinan bagi dua pengguna yang berbeda untuk berbagi kunci ssh yang sama, yang akan menggagalkan tujuan otentikasi .

Otentikasi berarti:
"menggunakan kunci ssh tertentu harus menyiratkan bahwa Anda seharusnya tahu siapa yang menggunakannya".

Halaman GitHub " Mengelola kunci penerapan " merinci berbagai akun menggunakan ssh:

  • Penerusan agen SSH : Penerusan agen menggunakan kunci SSH yang sudah disiapkan di mesin pengembangan lokal Anda saat Anda masuk ke server SSH dan menjalankan perintah git.
    Anda dapat secara selektif membiarkan server jarak jauh mengakses ssh-agent lokal Anda seolah-olah itu berjalan di server.
    Jadi tidak perlu mereplikasi kunci pribadi Anda di server.

  • Pengguna mesin : (ini adalah strategi "akun dummy") Lampirkan kunci ke akun pengguna. Karena akun ini tidak akan digunakan oleh manusia, ini disebut pengguna mesin.
    Anda akan memperlakukan pengguna ini dengan cara yang sama seperti Anda memperlakukan manusia, lampirkan kunci ke akun pengguna mesin seolah-olah itu adalah akun biasa.
    Berikan akses tim atau kolaborator akun ke repositori yang diperlukan aksesnya.
    Jadi satu kunci pribadi yang terkait dengan satu "pengguna mesin", satu kunci per server.

( DHa menunjukkan di komentar ke nomor batas kunci penerapan, dan fakta Anda hanya dapat memiliki satu akun pengguna mesin)

  • Menerapkan kunci (satu per repo GitHub) kunci SSH yang disimpan di server dan memberikan akses ke satu repo di GitHub.
    Kunci ini dilampirkan langsung ke repo, bukan ke akun pengguna .
    Alih-alih membuka pengaturan akun Anda, buka halaman admin target repo.
    Buka " Deploy Keys" dan klik " Add deploy key". Tempel kunci publik dan kirim.

Kali ini, kunci ssh tidak dilampirkan ke pengguna (di mana Anda dapat memberikan akses ke beberapa repo), tetapi ke satu repo.
Memberikan akses ssh untuk beberapa repo sama dengan "pengguna mesin".

Dalam hal otentikasi :

  • menggunakan kunci yang sama untuk beberapa repo tidak apa-apa jika dilakukan oleh pengguna (yang mengatakan kunci terkait dengan akunnya)
  • menggunakan kunci yang sama untuk beberapa repo TIDAK diperbolehkan jika kunci dipasang oleh sebuah repo, karena Anda sama sekali tidak tahu siapa yang mengakses apa.
    Itu berbeda dari "pengguna mesin" di mana "pengguna" dinyatakan sebagai kolaborator untuk banyak repo.
    Di sini (Deploy key), tidak ada "kolaborator" , hanya akses ssh langsung yang diberikan ke repo.
VonC
sumber
53
GitHub mendukung kunci publik Tingkat Akun , dan kunci Tingkat Proyek (alias Deploy Keys). Tidak mengizinkan penggunaan kembali kunci Tingkat Akun masuk akal, tetapi saya mengklaim bahwa tidak mengizinkannya untuk Deploy Keys tidak. Satu kunci Tingkat Akun saya memungkinkan akses ke semua proyek saya, jadi mengapa saya tidak bisa memiliki Kunci Penerapan yang memungkinkan akses ke beberapa proyek saya? Itu hanya lebih membatasi dan tidak menimbulkan kekhawatiran yang bisa saya lihat. Kekhawatiran Anda tentang membuka kemungkinan bagi dua pengguna berbeda untuk berbagi kunci ssh yang sama tidak muncul dalam skenario itu.
David Ebbo
@DavidEbbo Ini mungkin tidak muncul dalam gambar, tetapi kekhawatiran itu (dua pengguna berbeda untuk berbagi kunci ssh yang sama) adalah inti dari alasan mengapa kunci ssh tidak dibagikan.
VonC
21
Saya khawatir saya tidak mengikuti alasan Anda di sini. Saya bertanya tentang skenario yang sangat spesifik (gunakan Deploy Key di beberapa proyek), dan argumen Anda untuk itu tidak mungkin adalah memunculkan skenario yang tidak terkait (dua pengguna berbagi kunci ssh). Berpegang teguh pada skenario Deploy Key, apa hal negatif dari github yang mengizinkannya?
David Ebbo
6
@DavidEbbo Mengikuti help.github.com/articles/managing-deploy-keys , tidak satu pun dari tiga metode (Akun, Deploy atau akun Mesin) melibatkan berbagi kunci SSH pribadi untuk mengakses repo tersebut. Tetap secara eksklusif dengan skenario Deploy Key, karena ini adalah kunci di server , agar valid di beberapa repo berarti membagikan (atau mereplikasi) kunci pribadi pada beberapa repo. Itu mengurangi aspek otentikasi, dan jika kuncinya dikompromikan, menambah jumlah repo yang terekspos.
VonC
8
terima kasih, halaman itu memiliki info menarik. Saya akan menandai balasan Anda sebagai jawaban dalam satu atau dua hari jika saya tidak melihat yang lain, meskipun sejujurnya saya masih belum yakin dengan argumen tersebut. Memiliki kunci penerapan yang digunakan pada dua repo tidak lebih lemah daripada menggunakan kunci mesin yang memiliki akses ke kumpulan repo yang sama.
David Ebbo
11

Sayangnya, ini adalah skenario di mana github salah menafsirkan perbedaan antara pasangan kunci dan akun atau proyek.

Karena pasangan kunci digunakan untuk otentikasi dan otorisasi, ini secara efektif merupakan identitas. Akun Github adalah identitas lain. Menghubungkan akun github ke pasangan kunci secara efektif membuat pemetaan 1: N antara identitas berbasis akun github dan identitas pasangan kunci.

Sebaliknya, github memberlakukan pemetaan proyek 1: N ke identitas berbasis pasangan kunci. Analog dunia nyata adalah bahwa ada pintu yang memberikan akses ke proyek yang dapat dibuka oleh banyak orang yang berbeda. Tapi begitu salah satu dari mereka mendapatkan kunci pintu, mereka tidak bisa mendapatkan kunci lain untuk pintu lain, selamanya.

Masuk akal untuk tidak menggunakan kembali kunci sesering mungkin dari perspektif berisi pelanggaran jika sebuah kunci dikompromikan. Tapi itu hanya kebijakan administrasi yang baik . Tidaklah masuk akal untuk mencegah kunci digunakan lebih dari sekali pada prinsipnya . Bahwa ada beberapa kunci untuk beberapa pintu yang tidak pernah digunakan kembali, sekali lagi itu tergantung kebijakan .

Pandangan yang sedikit lebih kompleks adalah mengilustrasikan pasangan kunci sebagai peran . Anda dapat memiliki banyak pasangan kunci, dan karenanya menjalankan banyak peran. Kunci pribadi mengautentikasi Anda untuk peran tersebut.

Pemetaan kunci penerapan Github ke proyek menyatakan bahwa suatu peran tidak pernah dapat mencakup lebih dari satu tugas. Itu jarang realistis.

Tidak ada yang mengubah apa yang diizinkan oleh github, tentu saja.

Jens Finkhaeuser
sumber
1
Heh. Agak lucu bagaimana ini mendapat suara negatif, padahal itu lebih benar daripada jawaban yang diterima. Secara harfiah tidak ada hal ini yang mencegah berbagi kunci dengan banyak pengguna.
Jens Finkhaeuser
2

Saya butuh banyak pemikiran untuk merasionalisasi implikasinya dan menghasilkan skenario ini.

Bayangkan Anda membuat satu kunci penerapan untuk pengguna yang telah Anda tetapkan ke beberapa repositori. Sekarang Anda ingin mencabut kunci itu tetapi digunakan di banyak tempat. Jadi, alih-alih dapat mencabut semua akses, Anda mungkin secara tidak sengaja hanya mencabut sebagian akses.

Ini mungkin terdengar seperti keuntungan tetapi hubungan banyak-ke-satu ini sebenarnya secara inheren tidak aman setelah Anda mempertimbangkan faktor manusia. Ini karena Anda tidak dapat mengetahui dengan pasti apakah Anda benar-benar telah mencabut semua akses tanpa memeriksa setiap repositori dan membandingkan setiap kunci publik secara individual jika Anda lupa di mana Anda sebenarnya menetapkannya.

Jelas membuat frustasi untuk menetapkan dan mengelola begitu banyak kunci unik tetapi implikasi keamanannya jelas dengan bagaimana GitHub telah melembagakan kebijakan mereka: ketika Anda mencabut kunci, Anda dijamin akan mencabut semua akses yang diberikan oleh kunci itu karena hanya digunakan di satu tempat .

Zhro
sumber
1
Saya tidak yakin dengan penjelasan ini. Apa perbedaan yang mendasar dari mengizinkan satu pengguna untuk mengakses banyak repositori, yang jelas-jelas diizinkan? Jika Anda tidak lagi mempercayai pengguna itu, Anda harus menghapus mereka dari setiap repo.
David Ebbo
@ David: How is that fundamentally different from allowing one user to access multiple repositories, which is obviously allowedBisakah Anda menjelaskan ini lebih lanjut? Saya hanya memiliki akun Pengembang dan saya melihat bahwa Anda dapat menambahkan kunci ssh untuk akses seluruh akun (satu kunci untuk semua repositori) atau menambahkan kunci penerapan individu (satu kunci untuk setiap repositori). Ini masih merupakan hubungan satu-ke-banyak atau satu-ke-satu di mana mencabut kunci "satu" akan mencabut akses "semua" dalam kedua kasus.
Zhro
Untuk memperjelas lebih lanjut, tidak ada kesempatan (apa yang dapat saya katakan) untuk secara tidak sengaja menetapkan kunci dalam hubungan banyak-ke-satu di mana akses mungkin ada di tempat lain setelah dicabut. Ini tampaknya menjadi motivasi GitHub untuk pembatasan ini, tetapi saya hanya menebak-nebak.
Zhro
Cara saya melihat sesuatu, menerapkan kunci agak mirip 'pengguna anonim' yang tidak memiliki akun lengkap, tetapi masih mewakili semacam identitas. Perbedaannya adalah dalam kasus akun, Anda memberikan akses ke akun tersebut, yang secara tidak langsung memberikan akses ke semua kunci ssh di akun tersebut. Saat berada dalam kasus Deploy Key, Anda melewati abstraksi akun dan langsung memberikan akses ke kunci ssh. Namun di luar itu, saya tidak melihat kebutuhan keamanan yang berbeda. Jika Akun ATAU pemilik kunci penerapan menjadi jahat, Anda perlu menghapusnya dari setiap repo.
David Ebbo