Ssh anahtarlarını yönetmek için en iyi sistem? [kapalı]


42

Birkaç istemci bilgisayarım var (yani dizüstü bilgisayarlar, masaüstü bilgisayarlar vb.) Ve yönettiğim birkaç sunucu makinesine bağlanıyorum ve hepsine SSH ile giriş yapıyorum. Mantıklı olacak ssh anahtarlarını yönetmenin birkaç şemasını hayal edebiliyorum ve başkalarının ne yaptığını merak ediyorum.

Seçenek 1: Bir global kamu / özel anahtar çifti.

Bir genel / özel anahtarlık üretip, her istemci makineye özel anahtarı ve her sunucu makineye genel anahtarı koyardım.

Seçenek 2: Her sunucu makinesi için bir keypair.

Her sunucu makinede bir keypair üretir ve her özel anahtarı istemci makinelerime koyardım.

Seçenek 3: Her istemci makine için bir keypair.

Her istemci makinenin benzersiz bir özel anahtarı olur ve her sunucu makinesinde, bağlanmak istediğim her istemci makine için ortak anahtarlar bulunur.

Seçenek 4: Her müşteri / sunucu çifti için bir keypair

Tamamen denize düştü?

Bunlardan hangisi en iyisidir? Başka seçenekler var mı? Doğru konfigürasyonu değerlendirmek için hangi kriterleri kullanıyorsunuz?

Yanıtlar:


33

Kullandığım Seçenek 3: istemci makine başına bir keypair ve bana en mantıklı. İşte bazı nedenler:

  • Bir müşterinin güvenliği tehlikeye girerse, o anahtarın (ve yalnızca bu anahtarın) sunuculardan kaldırılması gerekir.
  • Tüm istemcilerden tüm sunuculara battaniye erişimi vermeden, nereden erişebileceğime karar verebilecek kadar esnek.
  • Çok uygun. Ssh-add için sadece 1 anahtar var, karışıklık yok.
  • Seçenek 4 üzerinden kurulumu ve yönetimi kolaydır

Seçenek 4 güzel, ama sadece çok fazla iş. Seçenek 3 , size daha az güçlükle% 98 kazandırır.


4
Seçenek 4'ün noktasını göremiyorum. Bu hiçbir şekilde işe yaramaz.
niXar

26

Ev ağı sunucularım, ofis sunucularım, danışmanlık yapan istemci ağ sunucularım ve hesaplarımdaki diğer çeşitli sistemler için kullanılan SSH kimlik anahtarlarında bazı ayrılıklar sağlamak istediğim için biraz daha karmaşık ama çok yönlü bir çözüm kullanıyorum.

Şimdi neredeyse sadece Linux iş istasyonlarından çalıştığımı ve bu yüzden LUKS şifrelemesini kullanarak ayarlayan bir USB anahtarım ve HAL daemon ile birlikte X11 pencere yöneticim LUKS şifreli sürücüyü algılayıp şifreleme şifresi sorulduğunda istemeye çalıştığını söyledi. monte edilebilir. Bunu şifreli bir sürücüye yaptığım gibi kaydederek SSH anahtarlarımı hiçbir iş istasyonunda saklamıyorum.

Sonra benim ~/.ssh/configdosyada aşağıdaki yapılandırma var :

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

% D OpenSSH tarafından kullanıcının ev dizini olarak çevrilmiştir ve ~ / .ssh dizininde ben yarattık keys.d düzgün monte edildiğinde şifreli USB sürücü üzerinde dizin yolu sembolik bağ olarak.

% L ifadesi yerel istemci makineleri makine adı ve olmaya çevrilmiştir % u yerel müşterinin kullanıcı adına çevrilecektir.

Bu yapılandırma SSH'nin 3 farklı ifade kullanarak bir anahtar aramasını sağlar. Örneğin, yerel müşterimin kullanıcı adı jdoeve yerel istemci makinemin adı examplehost, hem mevcut hem de uzak sunucu tarafından kabul edilen bir anahtar bulana kadar aşağıdaki sıraya bakacaktı.

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

Uzak sunucu kullanıcı adına özel bir anahtar aramak için % r ifadesini veya % u ve % l kullanıldıkları gibi uzak sunucu ana bilgisayar adı için % h bile kullanabilirsiniz .

Güncelleme: Şimdi sadece OpenPGP v2 akıllı kartımdaki kimlik doğrulama anahtarını okumak ve kullanmak için GnuPG gpg-agent'ı ssh-agent uyumluluğu ile kullanıyorum.


Vay, harika bir çözüm, teşekkürler! ~ /
.Ssh

İş, kişisel ve danışmanlık müşteri ağ sunucuları için işleri ayrı tutmanın oldukça uygun olduğu kanıtlandı ... Aralarında kimlik doğrulamayı karıştırmak istemiyorum, aynı zamanda benim için de kolay olmasını istiyorum.
Jeremy Bouse,

İnanılmaz! Bunu gerçekten seviyorum.
balu

Farklı istemci makineleri için farklı USB anahtarları kullandığınızı varsayıyorum. Aksi halde, hepsi aynı yerde depolanırsa, ayrı anahtarlardaki nokta nedir? İhlali durumunda hepsini iptal etmen gerekir. Tabii ki (ve muhtemelen) bir şeyi özlüyorum, bu sadece bazı şeyleri karmaşık hale getiriyor.
Halil Özgür

@ HalilÖzgür, Evet danışmanlık yapıyorum ve her zaman aynı anahtarı kullanmak istemiyorum. USB anahtarı şifrelenmiş ve herhangi bir bilgisayara bağlanmadığı için bir bağlantı yapmam gerekmediği sürece, sunucunun ihlal edildiğine dair bir endişe yoktur ve sürücü dosya sisteminin şifresini çözmek için kullanılan parola, iptal tuşlarını yeterince basit hale getirecek kadar uzundur.
Jeremy Bouse,

6

Her iki seçeneğinizi de ortadan kaldırırdım (bunlardan birinin seçenek 2 olması gerektiğinden şüpheliyim ;-), özel anahtarlar hassas verilerdir ve bunları mümkün olduğu kadar az yerde tutmak mantıklıdır). Kişisel olarak, bir bilgisayardan diğerine (hatta aynı bilgisayardaki bir dosyadan diğerine) özel bir anahtar kopyalamam, belki de yedekleme yapmak dışında. Çoğu şifreleme anahtarının aksine, bir SSH anahtarı kaybolursa, bu dünyanın sonu değildir (sadece yeni bir tane oluşturun, hiçbir veriyi kaybetmezsiniz).


Evet, uygun bir "Seçenek 2" olarak yeniden adlandırıldı "Asla özel bir anahtarı kopyalamayın" kuralını seviyorum. Bu iyi bir kural.
Slacy

1

Seçenek 3 ve kilit yönetimi ele almak için Kukla gibi bir şey kullanın.



Evet, bu o. Sitedeki bazı örneklere göz attığınızdan emin olun. Başkalarının daha önce ne yaptığını görmeye yardımcı olur - tekerleği yeniden icat etmenize gerek yok.
diq

1

Seçenek 3

Bu aynı zamanda bir müşterinin hangi sunuculara erişebileceğini kontrol etmenizi sağlar. Örneğin, X istemcisinin A ve B sunucularına erişmesi gerekiyorsa, ancak C veya D ise, genel anahtarını yalnızca bu ana bilgisayarlara kopyalarsınız.

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.