Sistem manajemen terpusat untuk kunci SSH?

27

Kami mencari untuk beralih ke manajemen SSH berbasis login, dan bertanya-tanya apakah ada sistem manajemen kunci yang akan memungkinkan kami untuk mengelola secara terpusat kunci akses di seluruh dunia.

Sistem idealnya harus memungkinkan mengeluarkan kunci per klien, dan mencabutnya jika perlu, memperbarui kunci mesin server dengan cepat.

Apakah ada yang tahu sistem seperti itu, baik komersial atau open source?

CATATAN: Untuk memperjelas, kami memerlukan manajemen kunci untuk sejumlah besar server cloud (mirip EC2), dan sejumlah kecil pengguna layanan. Saya kira tambalan LDAP + menyarankan di bawah ini mungkin cara untuk pergi.

ssh cloud keys SyRenity
sumber
7
Apakah hanya saya yang berpikir bahwa "kunci pribadi dan cloud" seperti "minum dan mengemudi". Keduanya membuat kesenangan secara terpisah tetapi tidak pernah berjalan bersama.
mailq
1
"Cloud" mungkin kata yang salah - kedengarannya seperti yang mereka inginkan adalah otentikasi terpusat, dengan konsistensi di seluruh dunia.
voretaq7
Hai. Persis - itulah yang kami cari.
SyRenity
Saya telah berjuang dengan masalah ini dengan beberapa lingkungan hibrid pelanggan saya. Ada juga pertanyaan tentang di mana menyimpan OPenLDAP atau pusat contoh dalam penyebaran cloud? Saya telah menggunakan webmin dari semua hal sebagai alat manajemen kunci, dan buku masak koki untuk menyinkronkan kunci ke node.
Tom H
Userify mencakup apa yang Anda cari (lihat serverfault.com/questions/647797/… )
Jamieson Becker

Jawaban:

8

Ada banyak cara untuk melakukan ini. Penyimpanan kunci LDAP telah disebutkan beberapa kali, dan saya telah melakukannya dan berfungsi, sejauh yang dilakukannya. LDAP memiliki keingintahuan manajemennya sendiri, yang membutuhkan pembelajaran.

Saya penggemar berat server sederhana dan tangguh yang memiliki ketergantungan jaringan eksternal minimal untuk hal-hal sederhana seperti otentikasi administrator, jadi saya condong ke arah strategi distribusi kunci SSH yang jauh lebih kuat - Saya memiliki sistem manajemen konfigurasi yang menanganinya. Kunci publik semua orang disimpan dalam sistem manajemen konfigurasi, dan di mana pun orang itu perlu bisa login, kunci mereka ditambahkan. Sistem konfigurasi juga tahu untuk menghapus kunci yang tidak ditentukan, jadi ketika seseorang meninggalkan atau kunci mereka berubah, itu adalah masalah sederhana menghapus konfigurasi kunci dan pada menjalankan sistem konfigurasi berikutnya, kunci tersebut dihapus.

womble
sumber
Pendekatan ini tentu saja bagus, dan seperti yang ditunjukkan Womble, ia mendapat keuntungan karena server tetap aktif dan berjalan (dan dapat diakses) jika LDAP turun - Setiap sistem yang didukung LDAP harus (berani saya katakan harus ) miliki di Setidaknya satu pengguna yang kuncinya didorong keluar seperti yang dijelaskan Womble. The downside adalah bahwa Anda harus melakukan menjalankan konfigurasi untuk membatalkan otorisasi pengguna. Bukan masalah untuk "akun darurat" dengan hanya beberapa pengguna yang diotorisasi. Masalah yang lebih besar untuk sejumlah besar akun :)
voretaq7
1
Anda benar-benar harus memiliki cara untuk memicu menjalankan konfigurasi massal, jadi itu bukan masalah besar untuk melakukannya untuk perubahan akun.
womble
Saya setuju, sayangnya kebutuhan / mentalitas bisnis tidak: Paranoia di banyak tempat (termasuk saya) menentukan bahwa konfigurasi push terjadi selama jam kerja, tetapi staf baru / staf cuti dapat terjadi kapan saja: - /
voretaq7
1
Jadi Anda senang membiarkan barang rusak selama hari kerja hanya karena Anda tidak dapat menjalankan konfigurasi push di siang hari? Hanya karena itu umum, bukan berarti itu tidak bodoh.
womble
2
Hai. Jadi ide yang bagus adalah menggunakan Boneka untuk ini, misalnya?
SyRenity
23

Pasangan kunci harus dibuat oleh pengguna.

Pengguna mempertahankan setengah privat - Anda seharusnya tidak pernah melihatnya. Jika Anda memiliki kunci pribadi seseorang dalam bentuk di mana Anda dapat membaca / menggunakannya Anda melakukan kesalahan keamanan.

Setengah publik diberikan kepada Anda (dengan mekanisme apa pun yang Anda inginkan: Formulir web, email, berikan-untuk-saya-di-CD), untuk dipusatkan sesuai keinginan Anda. Beberapa tempat menyimpan kunci publik di LDAP. Lainnya mendorong authorized_keysfile menggunakan sistem penyebaran mereka.

Di lingkungan saya, pengguna yang membutuhkan akses shell memberi saya kunci publik mereka. Kunci-kunci ini ditambahkan ke sistem LDAP kami, dan sshdberkonsultasi dengan kunci publik yang tercantum untuk setiap pengguna untuk mengotentikasi mereka, melalui patch Kunci Publik LDAP .
Ketika seseorang perlu menambahkan kunci tambahan atau mencabut kunci yang sudah ada, mereka memberi tahu admin, dan kami menanganinya. Akhirnya saat kita skala saya akan menerapkan sistem yang memungkinkan orang memutar kunci publik mereka sendiri.

Setiap situs kami memiliki sepasang server LDAP, disinkronkan ke master kami dengan replikasi LDAP, yang menjaga data konsisten (dan dapat diakses) di setiap lokasi.

Semua yang saya jelaskan dapat dilakukan dengan perangkat lunak sumber terbuka. Ada juga produk komersial yang melakukan hal yang sama.
Anda perlu meneliti opsi yang tersedia dengan lebih teliti dan memutuskan mana yang paling sesuai dengan lingkungan Anda. Jika Anda memiliki pertanyaan lebih lanjut (lebih spesifik) kami mungkin bisa lebih membantu.

voretaq7
sumber
Jadi pada dasarnya, Anda menyarankan menggunakan infrastruktur LDAP, dengan OpenSSH yang ditambal yang akan bekerja dengan LDAP? Seberapa baik timbangan ini dalam produksi? Bisakah itu mendukung sejumlah besar mesin? Kami hanya perlu mendukung sejumlah kecil pengguna layanan.
SyRenity
1
@SyRenity: LDAP mendukung replikasi dan pengelompokan sehingga berskala sangat baik
Hubert Kario
@SyRenity Secara teoritis Anda dapat mendukung mesin dalam jumlah tidak terbatas di lokasi yang tidak terbatas (pikirkan "penyebaran Active Directory yang benar-benar besar" - AD pada dasarnya adalah LDAP dengan beberapa aksesori modis). Untuk pengguna layanan saran saya adalah untuk membakukan mereka di lingkungan Anda dan mendorong standar /etc/passwddan /etc/groupfile (memungkinkan mesin untuk beroperasi secara normal dan layanan terkait untuk memulai / menjalankan bahkan jika LDAP tidak tersedia)
voretaq7
@ voretaq7 Berarti pengguna layanan akan dikelola secara terpisah dari LDAP, melalui manajemen konfigurasi?
SyRenity
@SyRenity ya - dan lebih penting lagi tersedia untuk layanan yang menggunakannya jika LDAP sedang down . Rencanakan kegagalan atau Anda akan mengalami bencana.
voretaq7
9

Keypairs tidak boleh dibuat di mana pun kecuali di komputer masing-masing pengguna. Kunci pribadi dinamai demikian karena suatu alasan.

Yang mengatakan, saya bisa melihat use case untuk semacam repositori terpusat dari kunci publik pengguna. Salah satu opsi adalah menyimpan kunci publik di OpenLDAP - versi terbaru OpenSSH dapat membaca kunci dari LDAP.

EEAA
sumber
2
Apakah kunci publik LDAP ada di arus utama OpenSSH sekarang? Saya hanya tahu tambalan LPK (yang bisa saya pastikan - ini berfungsi dengan baik). Juga +1 untuk menjaga kunci pribadi tetap pribadi.
voretaq7
@ voretaq7 Saya kira saya mendengarnya digabung ke dalam jalur utama, tapi saya belum memverifikasi itu sendiri. Kami melakukan direktori home yang dibagikan melalui NFS, sehingga mengurus distribusi utama kami untuk kami.
EEAA
+1 yah saya tidak tahu itu. itu akan menyelamatkan saya dari banyak masalah. itu sekarang dalam daftar hal-hal yang harus saya perhatikan.
Tom H
1

Ada banyak solusi komersial dan open source yang hebat, seperti Userify [1] (tempat saya bekerja), Universal Key Manager [2], SSH Key Box [3], dll. Itu tergantung pada apa kebutuhan Anda dan jika Anda menginginkannya. mencari sesuatu yang memusatkan manajemen sementara operasi desentralisasi (sehingga server Anda tidak bergantung pada otoritas pusat untuk masuk ... dalam hal itu, Anda mungkin tidak dapat masuk ke server mana pun, jika, katakanlah, server Anda Server LDAP sedang down!)

  1. https://userify.com

  2. https://www.ssh.com/products/universal-ssh-key-manager/

  3. https://www.sshkeybox.com

Lihat juga diskusi miring ini:

https://www.slant.co/topics/8010/~managers-for-ssh-keys

Jamieson Becker
sumber