Admin server mengirimi saya kunci pribadi untuk digunakan. Mengapa?

73

Saya seharusnya mengakses server untuk menghubungkan server pementasan dan server langsung ke loop penerapan kami. Admin di sisi mereka mengatur dua instance dan kemudian membuat pengguna di server untuk kita masuk ke SSH sebagai. Sebanyak ini aku terbiasa.

Dalam pikiran saya sekarang apa yang akan terjadi adalah saya akan mengirim mereka kunci publik saya yang dapat ditempatkan di dalam folder kunci resmi mereka. Namun sebaliknya mereka mengirim saya nama file id_rsayang di dalam file tersebut berisi -----BEGIN RSA PRIVATE KEY-----lebih dari email. Apakah ini normal?

Saya melihat sekeliling dan dapat menemukan ton sumber daya untuk menghasilkan dan mengatur kunci saya sendiri dari awal, tetapi tidak ada yang dimulai dari kunci pribadi server. Haruskah saya menggunakan ini untuk menghasilkan beberapa kunci untuk saya sendiri atau?

Saya akan menanyakan sistem admin secara langsung tetapi tidak ingin tampil bodoh dan menyia-nyiakan waktu semua orang di antara kita. Haruskah saya mengabaikan kunci yang dia kirimkan kepada saya dan meminta mereka untuk memasukkan kunci publik saya di dalam folder resmi mereka?

Toby
sumber
6
Saya tidak akan menyebutnya normal atau waras, tetapi karena Anda memiliki kunci pribadi (dengan asumsi mereka telah menambahkannya sebagai yang diotorisasi), Anda dapat menggunakannya karena Anda akan menggunakan kunci pribadi lainnya. Anda tidak memerlukan kunci publik yang sesuai, tetapi jika Anda menginginkannya, Anda selalu dapat membuatnya: askubuntu.com/a/53555/158442
muru
34
Melewati -----BEGIN RSA PRIVATE KEY-----email adalah hal menakutkan berikutnya setelah melihat seorang pengguna yang disebutkan '); DROP DATABASE;--dalam tabel nama pengguna Anda.
Dmitry Grigoryev
62
@DmitryGrigoryev tidak ada yang menakutkan untuk dilihat '); DROP DATABASE;--sebagai nama pengguna di tabel database Anda - ini menunjukkan bahwa Anda telah melarikan diri dari input pengguna dengan benar
HorusKol
19
Anda tentu saja tidak dapat 'menggunakannya karena Anda akan menggunakan kunci pribadi lainnya'. Yang ini tidak pribadi. Ergo itu tidak mungkin memenuhi fungsi yang telah dibuat. Itu harus dibuang dan admin UNIX dihukum berat. @muru
user207421
7
Siapa pun yang memiliki kunci pribadi ini memiliki akses ke server baru. Agaknya admin tetap memiliki akses tanpa perlu kunci, mengingat dia mampu mengatur server, jadi tidak ada ancaman tambahan dari akses yang tidak sah olehnya. Namun, karena ini adalah kunci Anda, sekarang ia dapat menyamar sebagai Anda. Ada juga kemungkinan bahwa orang lain selain Anda membaca email, dan kemudian mereka dapat menyamar sebagai Anda juga.
user253751

Jawaban:

116

Dalam pikiran saya sekarang apa yang akan terjadi adalah saya akan mengirim mereka kunci publik saya yang dapat ditempatkan di dalam folder kunci resmi mereka.

Apa yang "ada dalam pikiran Anda" seperti apa yang seharusnya terjadi sekarang adalah benar.

Email bukan saluran komunikasi yang aman, jadi dari sudut pandang keamanan yang tepat, Anda (dan mereka) harus mempertimbangkan bahwa kunci pribadi dikompromikan.

Bergantung pada keterampilan teknis Anda dan seberapa diplomatisnya Anda, Anda dapat melakukan beberapa hal berbeda. Saya akan merekomendasikan salah satu dari yang berikut:

  1. Buat pasangan kunci Anda sendiri dan lampirkan kunci publik ke email yang Anda kirim kepada mereka, dengan mengatakan:

    Terima kasih! Karena email bukan metode distribusi aman untuk kunci pribadi, bisakah Anda meletakkan kunci publik saya, sebagai gantinya? Itu terlampir.

  2. Berterimakasihlah kepada mereka dan tanyakan kepada mereka apakah mereka keberatan dengan Anda memasang keypair Anda sendiri, karena kunci pribadi yang mereka kirim harus dianggap dikompromikan setelah dikirim melalui email.

    Hasilkan keypair Anda sendiri, gunakan kunci yang mereka kirimkan kepada Anda untuk masuk pertama kali, dan gunakan akses itu untuk mengedit authorized_keysfile agar berisi kunci publik baru (dan hapus kunci publik yang terkait dengan kunci privat yang dikompromikan.)

Intinya: Anda tidak akan terlihat seperti orang idiot. Tapi, admin yang lain bisa dibuat terlihat seperti orang idiot dengan sangat mudah. Diplomasi yang baik bisa menghindarinya.


Edit dalam menanggapi komentar dari MontyHarder:

Tak satu pun dari tindakan yang saya sarankan melibatkan "memperbaiki berbagai hal tanpa memberi tahu admin lain tentang kesalahannya"; Saya hanya melakukannya secara halus tanpa melemparkannya ke bawah bus.

Namun, saya akan menambahkan bahwa saya juga akan menindaklanjuti (sopan) jika petunjuk halus tidak diambil:

Halo, saya melihat Anda tidak menanggapi komentar saya tentang email sebagai saluran tidak aman. Saya ingin yakin bahwa ini tidak akan terjadi lagi:

Apakah Anda mengerti mengapa saya membuat poin ini tentang penanganan aman kunci privat?

Terbaik,

Toby

Wildcard
sumber
9
+1 Jawaban terbaik. Dan saya akan menambahkan: berhati-hatilah karena sysadmin ini terbukti tidak kompeten. Lebih baik Anda kembali tertutup ketika (dan bukan jika ) dia akan mengacaukan server untuk selamanya.
dr01
2
Terima kasih. Saya menggunakan beberapa ungkapan yang rumit dan mengirimkan kunci publik saya ke seberang. Semua terlihat diselesaikan tetapi saya akan membatalkan otorisasi kunci yang dia kirimkan kepada saya sekarang.
Toby
27
Bukannya admin lain "bisa dibuat agar terlihat seperti orang idiot". Itu karena admin lain melakukan sesuatu yang bodoh. Saya hanya dapat memikirkan satu skenario di mana kunci pribadi harus dibagi di antara mesin, dan di situlah kumpulan server diakses melalui nama yang sama (resolusi DNS round-robin dll.) Dan harus menyajikan Kunci Host SSH yang sama sehingga proses otomatis akan menerima bahwa mereka adalah nama itu. Dan dalam hal itu, orang yang sama akan menjadi admin dari semua server, dan akan menangani transfer tanpa melibatkan pihak luar.
Monty Harder
21
@ zwol Di pekerjaan saya, kami memiliki filosofi "tidak disalahkan" yang memahami bahwa kami akan membuat kesalahan, tetapi menjadikannya prioritas tinggi untuk tidak membuat kesalahan yang sama dua kali. Tetapi untuk tidak membuat kesalahan yang sama dua kali, Anda harus tahu itu adalah kesalahan, itulah sebabnya saya tidak bisa memilih-pilih jawaban yang menyarankan OP hanya memperbaiki hal-hal tanpa memberi tahu admin lain apa yang salah. Saya memilih untuk menyebut kesalahan itu 'bodoh' daripada memanggil nama admin dengan tepat karena alasan yang Anda sebutkan. (Tapi saya tidak yakin tanda kurung kesimpulan Anda mengartikulasikan perbedaan yang berarti.)
Monty Harder
8
@LightnessRacesinOrbit, saya kira Anda mungkin memiliki pemahaman yang tidak lengkap tentang arti "diplomasi." Sudahkah Anda mencoba menjernihkannya dalam kamus yang baik, seperti Kamus Internasional Baru Ketiga Webster?
Wildcard
34

Haruskah saya mengabaikan kunci yang dia kirimkan kepada saya dan meminta mereka untuk memasukkan kunci publik saya di dalam folder resmi mereka?

Ya, itulah yang harus Anda lakukan. Inti dari kunci privat adalah kunci privat , artinya hanya Anda yang memiliki kunci privat. Karena Anda menerima kunci itu dari admin, ia juga memilikinya. Jadi dia bisa menyamar sebagai kamu kapan saja dia mau.

Apakah kunci itu dikirimkan kepada Anda melalui saluran aman atau tidak tidak relevan: bahkan jika Anda telah menerima kunci pribadi Anda secara langsung, itu tidak akan mengubah apa pun. Meskipun saya setuju dengan komentar bahwa kunci kriptografi sensitif yang dikirim melalui email adalah hadiah: admin Anda bahkan tidak berpura-pura ada semacam kebijakan keamanan di tempat.

Dmitry Grigoryev
sumber
6
Dan karena OP tidak punya cara untuk mengetahui seberapa aman mesin admin (dari cerita, mungkin sangat tidak aman), ia harus berasumsi bahwa kunci privat (atau akan) bocor ke orang lain. Mengirim kunci pribadi melalui email hanyalah fakta bonus untuk ketidaktahuan infosec.
dr01
1
Anda dapat berasumsi bahwa admin yang dapat membuat pengguna tidak akan memerlukan kunci pribadi Anda untuk menyamar sebagai Anda.
Max Ried
3
@ MaxRied Itu mungkin sulit dilakukan dengan log keamanan yang tepat di tempat. Dengan kunci pribadi Anda, ia bahkan tidak perlu membuat mock log. Ini seperti memiliki kemampuan untuk mengatur ulang kata sandi Anda dan mengetahui kata sandi Anda.
Dmitry Grigoryev
@DmitryGrigoryev Dia selalu bisa menambahkan kunci lain ke file otor_keys Anda ...
Max Ried
4
@ MaxRied yang saya maksud /var/log/secureatau mirip , saya cukup yakin trik ruang tidak akan menipu yang satu ini.
Dmitry Grigoryev
14

Bagi saya kelihatannya admin menghasilkan sepasang kunci privat / publik untuk Anda, menambahkan kunci publik ke otor_keys dan mengirimkan Anda privat. Dengan cara ini Anda hanya perlu menggunakan kunci pribadi ini untuk sesi ssh Anda dengan server. Tidak perlu membuat pasangan kunci sendiri atau mengirim admin kunci publik ke kunci privat Anda yang kemungkinan rusak (selalu berpikir terburuk: P).

Namun, saya tidak akan mempercayai kunci pribadi yang dikirimkan kepada Anda melalui surat yang tidak dienkripsi.

Pendekatan saya adalah: gunakan kunci pribadi untuk login sekali, tambahkan kunci publik Anda sendiri ke otor_keys di server (mengganti kunci publik asli) dan buang kunci-pribadi-email ini. Anda kemudian dapat mengucapkan terima kasih kepada admin, bahwa dia memberi Anda kunci pribadi tetapi Anda lebih suka informasi / kunci tersebut tidak dikirim melalui email (/ sama sekali).

pengguna204269
sumber
3
@Toby Satu-satunya alasan yang dapat saya bayangkan untuk mereka mengirim kunci pribadi adalah bahwa mereka tidak memahami alat yang mereka gunakan. Dan Anda dapat menggunakan -ipada baris perintah untuk memilih kunci privat mana yang akan digunakan.
kasperd
18
@kasperd Alasan yang dapat saya bayangkan adalah sysadmin yang bekerja terlalu keras yang telah memutuskan bahwa risiko mengirim kunci pribadi melalui email lebih besar daripada kerumitan mencoba menjelaskan kepada pengguna yang kurang paham teknologi bagaimana cara menghasilkan pasangan kunci yang benar dan mengirim kunci publik kembali.
mattdm
1
Poin bagus yang bisa Anda perbaiki sendiri. Lebih baik melakukannya sendiri segera daripada menunggu admin menginstal kunci publik untuk keypair baru. Menghindari penggunaan kunci pribadi yang tidak lagi rahasia tidak membantu apa-apa; itu hanya memberi eavesdropper potensial lebih lama untuk menggunakannya sebelum Anda bisa masuk dan menghapusnya authorized_keys(setelah menambahkan + menguji Anda sendiri).
Peter Cordes
4
@mattdm Itu ... sepenuhnya logis, namun menakutkan. Seseorang yang tidak dapat menghasilkan pasangan kunci dan mengirim saya kunci publik mungkin tidak akan melakukan jauh lebih baik dengan kunci pribadi yang saya berikan kepadanya.
Monty Harder
1
@mattdm, cukup adil tetapi karena saya adalah orang yang memintanya melakukan semua ini, saya merasa sulit untuk percaya dia pikir saya tidak tahu bagaimana terhubung dengan ssh. Jika ada langkah-langkah yang dia ambil lebih membingungkan karena saya hanya tahu cara umum dasar menggunakan kunci publik. : x
Toby