SSH ortak anahtarlarını dağıtmak için bir sistem


26

Birkaç kişi tarafından yönetilen birçok farklı sistemimiz var. Bu sistemlere erişmek için SSH ortak anahtar kimlik doğrulamasını kullanmayı seçtik. Bu, idari hesap şifrelerini yönetmeye veya paylaşmaya gerek olmadığı, şifreleri çeşitli sistemlere (sadece özel anahtarınızın şifresini ifade eden) hatırlama gerekmediği, her uzaktan kumanda komutuyla etkileşime girme (şifre girme) gerekmediğinden harika bir işlemdir. .

Sorun, sistemlere kurulu ortak anahtarların bir şekilde yönetilmesi gerektiğidir. İnsanlar gelir ve gider, anahtarlar tehlikeye girebilir, sorumluluklar değişebilir (bugün bir sisteme girmeye yetkili bir kişi yarın farklı bir sisteme erişmeye yetkili olabilir). Şu anda, bunu gerektiren her hesapta ~ / .ssh / yetkili_keys dosyalarını el ile düzenleyerek yönetiyoruz, ancak bu çok fazla iş ve hatalara açık.

Böyle bir senaryoda ortak anahtarları yönetmek için hazır bir araç var mı? Kendi çözümlerin var mı? Yoksa sistemleri bu şekilde yönetme fikri yanlış mı?


Sorunuza gerçekten cevap veremiyorum, ancak okuduğumda bir çeşit veritabanı sistemi için çığlık attığını duyabiliyordum.
John Gardeniers

Aslında, 'arka uç' ('anahtar sunucu') üzerinde bir veritabanı için bir yer görebiliyorum, ancak orada veritabanı erişimini sınırlandırmayı tercih ediyorum ve anahtarların SSH kanalı üzerinden dağıtılmasını tercih ediyorum. Yönetilen sistemlerde başka herhangi bir iletişim kanalı açmamak. Aslında hazır ve kanıtlanmış bir şeyi tercih etsem de, kendimi böyle bir aracı / sistemi uygulayabildiğimi hissediyorum.
Jacek Konieczny

Yanıtlar:


18

Pulegium tarafından daha önce belirtildiği gibi, Puppet , Chef , Bcfg2 veya cfengine gibi herhangi bir jenerik konfigürasyon yönetimi yazılımı görevi yerine getirebilir.

Yana authorized_keys dosyası karmaşık olmadığını, ayrıca kullanabilirsiniz rsync ya da benzeri bir (D) SCM Git ya hg bu dosyayı yönetmek için. Sunucularınızın birinde "ana" bir dosyaya sahipsiniz ve rsync / git / hg /… ile gönderin. Diğer tüm sunucularda, ana kopyayı düzenli aralıklarla (değiştirildiyse) alan ve doğru yerel konuma kopyalayan bir cron işi çalıştırıyorsunuz. Heck, bu bile saf HTTP veya FTP ile çalışır.

Alt satırda: yetkili_keys dosyanızın bir "ana" kopyasını alın ve güncelleyin. "İstemciler" in (şu anki yetkili_key dosyasının olması gereken bilgisayarlar) ana sunucunuzdan almasına ve yerel olarak dağıtmasına izin verin.


1
~ 200 Linux sunucusunu yönetmek için rahatlıkla kukla kullanıyoruz (pub anahtarları sadece bir kullanıcının niteliği olarak zorlamak için bir dosyadır).
ForgeMan

1
Bu cevabı kabul edeceğim sanırım daha iyi olamayacağım. Bana göre seçenekler şu şekilde görünüyor: 1. Şu anki gibi şeyleri koruyun 2. Yetkili_keys dosyalarını yönetmek için kendi araç zincirini oluşturun 3. Kukla veya Şef gibi sunucuları yönetmek için mevcut, genel bir araç kullanın… bu araçlar için çok büyük görünüyor bu basit görev. 4. Diğer kimlik doğrulama / yetkilendirme mekanizmalarını kullanın (Kerberos gibi)… ancak bu aynı zamanda basit bir görev için çok karmaşık bir araç gibi görünüyor.
Jacek Konieczny

bu sistem, ana kopyanın çekildiği kanal kadar güvenlidir.
saat

1
Ansible, ssh üzerinden yetkili anahtar dosyalarına takılmak için bir modüle sahip çok hafif bir CM sistemidir. Bkz ansible.cc/docs/modules.html#authorized-key
RS

11

OpenSSH için bir LDAP sunucusundan ortak anahtarlar kullanmasına izin veren bir yama var, ancak bu yalnızca gerçek / hesap kontrolleriniz de bu LDAP sunucusuna karşı yapıldıysa (ortamım nasıl kurulursa) mantıklı geliyor. Ayrıca yalnızca LDAP yapılandırmanız kadar güvenlidir (bu nedenle SSL ve doğrulama tuşlarını kullanmak istiyorsunuz).

Bkz http://code.google.com/p/openssh-lpk/ yama ve daha detaylı bilgi için. Varsayılan olarak bu düzeltme ekiyle gelen işletim sistemlerini bilmiyorum, ancak FreeBSD kullanıyorsanız, OpenSSH'yi bağlantı noktalarından kullanıyorsanız isteğe bağlı bir düzeltme ekidir.


1
Tesadüfen pam_ldap kullanmak ayrıca "bugün makineye erişme yetkisi var olan bir makineye yarın erişme yetkisi verilebilir" sorununu da çözmenizi sağlar - sorunla ilgileniyorsanız pam_ldap ile okuyun ...
voretaq7

5

Güvenlik duvarı kuralları ile aynı olan çok kolay bir çözüm çalıştırmak

örnek dosya hosts.conf:

192.168.0.1
192.168.2.99
192.168.2.100

distribute.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;

bütün sihir bu :-)


5

Şu anda SSH KeyDB'yi kontrol ediyorum . Rolleri, sunucuları ve kullanıcıları yönetmek, kullanıcı anahtarlarını dağıtmak, ana bilgisayar anahtarlarını toplamak, vb. Tam olarak yapması gerekiyor. Hatta "konumlar" denilen bir şeye sahip.

Henüz hepsini çözmedim ve tam olarak çalışıp çalışmadığından emin değilim. Ancak kod python'dadır ve oldukça kolay yönetilebilir görünmektedir, bu yüzden onu tozdan arındırmak ve çalışmak zor olmamalıdır.


1

Ne demek istediğinizi tam olarak bilmiyorum, ne de değişmek isteyip istemediğinizi de bilmiyorum ama Kerberos aradığınız droid. Bu, problemlerinizi zarif bir şekilde çözecek ve hem insanları hem de makineleri doğrulayacaktır.


1

Çözmeye çalıştığınız iki (genellikle 3'e dönüşen) farklı sorunlarınız var:

  • Kimlik doğrulama (Sen kimsin?)
  • Yetkilendirme (Bu sunucuya erişme izniniz var mı?)
  • Denetim (Ne yaptınız?)

Genel anahtar auth, bazen kimlik doğrulaması yapmanın iyi bir yoludur, ancak yetkilendirmeyi ele almaz. Public-key auth'yu sevmiyorum, çünkü yerinde iyi kontrolleriniz olmadıkça (özellikle dahili olarak) ödün vermek çok kolaydır.

Kerberos gibi çözümler devreye giriyor. Windows dünyasında, Active Directory bu sorunu çözer. Unix dünyasında, hem iyi bir şey hem de kötü bir şey olan çok sayıda seçenek vardır.

AD benzeri bir Kerberos / LDAP / DNS sistemi kurmayı ve hızlı bir şekilde çalıştırmayı kolaylaştıran bir yazılım paketi olan Red Hat FreeIPA projesine bakarım .


Kimlik doğrulama, yetkilendirme ve denetim arasındaki farkı anlıyorum. Ve SSH'nin 'yetkili_ anahtarları' hem kimlik doğrulama hem de yetkilendirme verisi sağlar. Mükemmel olmaktan uzak, ama basit. Basitlik de güvenlik açısından çoğu zaman büyük bir avantajdır. Kerberos, karmaşık altyapısı ile security_keys dosyaları ile birlikte ssh'den daha fazla güvenlikle başarısız olabilir. Yine de, biri ya da diğeri daha güvenli olduğu anlamına gelmez.
Jacek Konieczny

Yetkili_keys dosyalarının yönetimi bir avuç sunucu için np'dir, ancak hızla yönetilmesi imkansız olan bir noktaya ulaşırsınız. Bunun "kötü" bir çözüm olduğunu söylemeye çalışmıyordum. Aynı şekilde, Kerberos'taki karmaşıklıklar iki sunucu için uygun değildir ... ancak kerberos'un tasarım / uygulama yatırımı daha büyük bir ortamda buna değer.
duffbeer703

1

Sen kullanabilirsiniz Bcfg2 ile bcfg2 hesaplara dağıtmak authorized_keys. Eklenen bonus olarak, kullanıcıları ve grupları kontrol etme olanağına sahip olacaksınız.

Bcfg2, SSHbase /etc/ssh/ssh_known_hostsile de ağrısız bakım sağlar .


Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.