Sistem untuk mendistribusikan kunci publik SSH

26

Kami memiliki banyak sistem berbeda yang dikelola oleh beberapa orang. Kami telah memilih untuk menggunakan otentikasi kunci publik SSH untuk mengakses sistem tersebut. Ini berfungsi dengan baik, karena tidak perlu mengelola atau berbagi kata sandi akun administratif, tidak perlu mengingat kata sandi ke berbagai sistem (hanya frase sandi untuk kunci pribadi Anda), tidak perlu berinteraksi (memasukkan kata sandi) dengan setiap perintah jarak jauh .

Masalahnya adalah, kunci publik yang diinstal pada sistem perlu dikelola entah bagaimana. Orang-orang datang dan pergi, kunci dapat dikompromikan, tanggung jawab berubah (seseorang yang berwenang untuk memasuki satu sistem hari ini mungkin diizinkan untuk mengakses yang berbeda besok). Saat ini kami mengelolanya dengan mengedit secara manual file ~ / .ssh / Authorized_key pada setiap akun yang membutuhkannya, tetapi itu banyak pekerjaan dan rawan kesalahan.

Apakah ada alat yang siap untuk mengelola kunci publik dalam skenario seperti itu? Apakah Anda punya solusi sendiri? Atau apakah seluruh gagasan mengelola sistem dengan cara ini cacat?

ssh ssh-keys public-key

— Jacek Konieczny
sumber

Saya tidak bisa menjawab pertanyaan Anda, tetapi ketika saya membacanya, saya hanya bisa mendengarnya berteriak untuk semacam sistem basis data.

— John Gardeniers

Memang, saya dapat melihat tempat untuk database di 'backend' ('server kunci'), meskipun saya lebih suka membatasi akses database di sana dan memiliki kunci didistribusikan di saluran SSH. Tidak membuka saluran komunikasi lain pada sistem yang dikelola. Bahkan saya merasa mampu mengimplementasikan alat / sistem itu sendiri, meskipun saya lebih suka sesuatu yang siap dan terbukti efektif.

— Jacek Konieczny

18

Seperti yang telah disebutkan oleh pulegium, perangkat lunak manajemen konfigurasi generik seperti Puppet , Chef , Bcfg2 , atau cfengine dapat menyelesaikan tugas.

Karena file Authorized_key tidak terlalu rumit, Anda juga dapat menggunakan rsync atau (D) SCM seperti git atau hg untuk mengelola file ini. Anda memiliki file "master" di salah satu server Anda dan melayani melalui rsync / git / hg /…. Di setiap server lain Anda menjalankan tugas cron yang secara berkala mengambil salinan master (jika diubah) dan menyalinnya ke lokasi lokal yang benar. Heck, ini bahkan akan bekerja dengan HTTP atau FTP murni.

Intinya adalah: Memiliki satu salinan "master" dari file Authorized_key Anda dan memperbaruinya. Biarkan "klien" (komputer, yang seharusnya memiliki file otor_keys saat ini) mengambilnya dari server master Anda dan menyebarkannya secara lokal.

— Joseph
sumber

1

Kami dengan nyaman menggunakan boneka untuk mengelola ~ 200 server Linux (kunci pub hanyalah file yang harus ditegakkan sebagai atribut pengguna).

— ForgeMan

1

Saya akan menerima jawaban ini karena sepertinya saya tidak akan menjadi lebih baik. Tampaknya pilihan bagi saya adalah: 1. Menjaga keadaan seperti sekarang. 2. Membangun rantai alat sendiri untuk mengelola file yang diotorisasi. 3. Menggunakan beberapa alat umum yang ada untuk mengelola server, seperti Wayang atau Koki ... meskipun alat itu tampaknya terlalu besar untuk tugas sederhana ini. 4. Gunakan mekanisme otentikasi / otorisasi lainnya (seperti Kerberos) ... meskipun ini juga alat yang terlalu canggih untuk tugas yang sederhana Terima kasih.

— Jacek Konieczny

sistem ini seaman saluran tempat salinan master ditarik.

— tahun

1

Ansible adalah sistem CM yang sangat ringan yang memiliki modul untuk membuat muck dengan file kunci yang diotorisasi melalui ssh. Lihat ansible.cc/docs/modules.html#authized-key

— RS

11

Ada tambalan yang tersedia untuk OpenSSH yang memungkinkannya untuk menggunakan kunci publik dari server LDAP, tetapi ini hanya masuk akal jika pemeriksaan auth / akun Anda juga dilakukan terhadap server LDAP tersebut (yang merupakan cara pengaturan lingkungan saya mengatur). Juga hanya seaman konfigurasi LDAP Anda (jadi Anda ingin menggunakan SSL & kunci verifikasi).

Lihat http://code.google.com/p/openssh-lpk/ untuk tambalan dan detail lebih lanjut. Saya tidak tahu OS apa pun yang dikirimkan dengan tambalan ini secara default, tetapi jika Anda menjalankan FreeBSD itu tambalan opsional jika Anda menggunakan OpenSSH dari port.

— voretaq7
sumber

1

Kebetulan menggunakan pam_ldap juga memungkinkan Anda memecahkan masalah "seseorang yang diberi izin untuk mengakses mesin A hari ini mungkin tidak diizinkan untuk mengaksesnya besok" - bacalah di pam_ldap jika Anda tertarik dengan aspek itu ...

— voretaq7

5

saya menjalankan solusi yang sangat mudah, yang melakukan hal yang sama dengan aturan firewall

contoh file hosts.conf:

192.168.0.1
192.168.2.99
192.168.2.100

mendistribusikan.sh:

#!/bin/bash
for d in `cat ./hosts.conf`; do
  echo "copying to $d ...";
  scp /root/.ssh./authorized_keys root@$d:/root/.ssh./authorized_keys
done;

itulah seluruh keajaiban :-)

— bmaeser
sumber

5

Saat ini saya sedang memeriksa SSH KeyDB . Ini dimaksudkan untuk melakukan hal itu, mengatur peran, server dan pengguna, mendistribusikan kunci pengguna, mengumpulkan kunci host dll. Bahkan memiliki sesuatu yang disebut "lokasi".

Saya belum menyelesaikan semuanya dan saya tidak yakin apakah itu berfungsi sepenuhnya. Namun kode ini dalam python dan tampaknya cukup mudah dikelola, jadi seharusnya tidak terlalu sulit untuk membersihkannya dan membuatnya berfungsi.

— andsens
sumber

1

Saya tidak yakin apa yang Anda maksudkan dengan banyak orang, saya juga tidak tahu apakah Anda mau berubah, tetapi Kerberos adalah droid yang Anda cari. Itu akan menyelesaikan masalah Anda dengan elegan, dan akan mengotentikasi orang dan mesin.

— pboin
sumber

1

Anda memiliki dua (yang biasanya berubah menjadi 3) masalah berbeda yang Anda coba selesaikan:

Otentikasi (Siapa kamu?)
Otorisasi (Apakah Anda diizinkan mengakses server ini?)
Audit (Apa yang Anda lakukan?)

Kunci publik kunci kadang-kadang merupakan cara yang baik untuk otentikasi, tetapi tidak membahas otorisasi sama sekali. Saya tidak suka autor kunci publik, karena sangat mudah untuk berkompromi (terutama secara internal) kecuali Anda memiliki kontrol yang baik.

Di situlah solusi seperti Kerberos ikut bermain. Di dunia Windows, Active Directory memecahkan masalah ini. Di dunia Unix, ada banyak pilihan, yang merupakan hal yang baik dan yang buruk.

Saya akan memeriksa proyek Red Hat FreeIPA , yang merupakan kumpulan perangkat lunak yang membuatnya mudah untuk menjalankan dan menjalankan sistem Kerberos / LDAP / DNS seperti-AD dan berjalan dengan cepat.

— duffbeer703
sumber

Saya mengerti perbedaan antara otentikasi, otorisasi, dan audit. Dan 'otor_keys' SSH menyediakan data otentikasi dan otorisasi. Jauh dari sempurna, tetapi sederhana. Dan kesederhanaan seringkali merupakan keuntungan besar, juga dalam keamanan. Kerberos, dengan infrastrukturnya yang rumit mungkin gagal-keamanan lebih dari ssh dengan file yang diotorisasi. Padahal, itu tidak berarti yang satu lebih aman.

— Jacek Konieczny

Mengelola file dengan otorisasi adalah np untuk beberapa server, tetapi Anda dengan cepat mencapai titik di mana tidak mungkin untuk mengelola. Saya tidak mencoba mengatakan bahwa ini adalah solusi "buruk". Demikian juga, kompleksitas di Kerberos tidak sesuai untuk dua server ... tetapi investasi dalam desain / implementasi kerberos layak dilakukan di lingkungan yang lebih besar.

— duffbeer703

1

Anda dapat menggunakan Bcfg2 dengan akun bcfg2 untuk mendistribusikan authorized_keys. Sebagai bonus tambahan, Anda akan memiliki kemampuan untuk mengontrol pengguna dan grup.

Bcfg2 memungkinkan pemeliharaan tanpa rasa sakit /etc/ssh/ssh_known_hostsdengan SSHbase juga.

— myroslav
sumber

1

Ada juga SKM

— andsens
sumber