SSH kullanarak çok sayıda sunucuya bağlanmak için kullandığım az sayıda farklı iş istasyonum (iPhone gibi istemci cihazları) var.
Başlangıçta PKI'yi öğrendiğimde, iş istasyonumda hemen her yerden kullanmaya başladığım (yani dizüstü bilgisayarıma kopyaladım, vb.) Tek bir anahtar çifti oluşturdum ve tüm sunucu hesaplarıma bağlanmak için kullandım.
O zamandan beri, bunun her yerde tek bir şifre kullanmaya benzer olduğu fikrini geliştirdim ve erişimi seçici olarak iptal etmem gerekebilir, ör. iş istasyonumdan biri tehlikeye girerse.
Temelde anahtar çiftleri ile başa çıkmak için kişisel bir strateji geliştirmeye çalışıyorum:
Kullanılabilirlik için pragmatik kalırken, anahtar çiftleri genel kullanım için güvenli bir şekilde düşünmenin doğru yolu nedir? (yani, her bağlantı noktası için tek kullanımlık anahtar çiftlerinin de mantıklı olduğunu düşünmüyorum.)
Bir anahtar çiftinin, geçmişte yaptığım gibi tüm erişim noktalarından ("me-everywhere-id_rsa") küresel olarak bir kişisel kimliği temsil etmesi yanlış mıdır yoksa şu anki benzersiz bir istemci-kullanıcı kombinasyonunun her zaman temsil edilmesi gerektiğini düşünüyor muyum? kendi anahtarı ("me-on-my-personal-laptop-id_rsa") daha uygun mu?
Tüm sunuculara bağlanmak için aynı anahtarı mı kullanıyorsunuz, yoksa hangi koşullarda ayrı bir anahtarı basmayı düşünüyorsunuz?
Kimlik doğrulama alanı başına bir anahtar almayı tercih ederim. Bu nedenle, işteki her masaüstü veya sunucu makinesi için (hepsi fiziksel olarak güvenli ve tek bir yönetici grubunun kontrolü altında), bir özel anahtarım var. Yeni ev bilgisayarımda eski ev bilgisayarımla aynı özel anahtarı kullanıyorum. Dizüstü bilgisayarlarda ve diğer mobil cihazlarda farklı tuşlar kullanıyorum. Bu yaklaşım hassas risk yönetimine izin verir: Anahtarları ayrı ayrı iptal edebilir ve hesaplarımın belirli makinelerde belirli anahtarlara izin vermeyerek artan bir sızıntıya dahil olma olasılıklarını sınırlayabilirim (çok fazla yapmıyorum, ancak bir seçenek paranoyak için).
Karmaşık bir şey yapmadığınız sürece, ortak anahtarları kopyalamak o kadar da zor değildir. Yetkili anahtarların büyük bir listesini tutabilir ve her yerde senkronize edebilirsiniz; bir cihazı kaydetmek, bu listeye bir öğe eklemek ve değişikliği itmek anlamına gelir. İlk etapta merkezi bir veri havuzunuz varsa, bu, özel anahtarı çekmekten daha fazla iş değildir.
Ayrı özel anahtarlara sahip olmanın en belirgin avantajı, ayrı ayrı iptal edebilmek olsa da, bunların da kullanılabilirlik avantajı olduğunu unutmayın: A makinesindeki bir sistem yöneticisi, üzerinde bulunduğunuz C makinesinin anahtarını iptal etmeye karar verirse, hala C'nin anahtarını kabul eden ve anahtarı A tarafından kabul edilen bir B makinesi bulabilirsin. Bu oldukça ezoterik görünüyor, ancak bu bana bir kez oldu ( Debian'ın RNG'lerini tohumlamadığımda, sadece kara listeye alınmış bir anahtara güvenmemeye sevindim, oysa acil bir durumda bir anahtarı iptal etmek zorunda kalmadım.
Her makine çifti için ayrı bir anahtar çifti tutmanın teorik bir yararı bile vardır, çünkü ayrı iptallere izin verir. Ancak fayda son derece küçüktür ve yönetim çok daha zordur (yetkilendirme listelerini artık yayınlayamazsınız). Anahtar yönetimini basitleştirmek, ortak sırlara göre ortak anahtar şifrelemesinin kritik bir avantajıdır.
Ana noktayı zaten gördünüz: Makinelerinizden biri tehlikeye atılmışsa, bu makinede bulunan özel anahtarın "iptal edilmesi" gerekir: bu anahtarı kullanarak daha fazla kimlik doğrulama girişimini reddetmek için bağlandığınız tüm sunucuları yapılandırmanız gerekir (örn.
.ssh/authorized_keys sunucu). Özel anahtarı bir parola (veya parola) ile güvenceye almaktan oluşan bir azaltma tekniği vardır. Bu bir fiyatla gelir, yani şifreyi yazmanız gerekir (
ssh-agent bunun için oldukça kullanışlı olabilir); Öte yandan, bu durum saldırganın geçici olarak özel anahtarı almasını engelleyebilir (bu uzlaşma türüne bağlıdır, ancak tam bir makinenin hırsızlığı ise - mobil cihazlarla birlikte makul bir senaryo - o zaman parola özel anahtara anında erişim sağlayın ve sunucuları yeniden yapılandırmanız için size biraz zaman verin).
"PKI" nin "Ortak Anahtar Altyapı" anlamına geldiği ve SSH'nin bu açıdan temel olduğu söylenebilir. Tam bir PKI'da sertifikalar , yetkilendirme ve iptali merkezileştirme ile birlikte kullanılır. Sertifikalarla:
Sertifikalarla ilgili en iyi şey, kararları merkezileştirmenizdir; bu, pratikte, istemci makinelerinizden 20 sunucuya bağlanır ve ardından yeni bir istemci makine eklerseniz, yeni genel anahtarı manuel olarak tüm 20 sunucu.
OpenSSH , 5.4 sürümünden (8 Mart 2010'da yayımlanmıştır) beri, sertifikalar için bazı destekleri vardır; için man sayfasındaki isimsiz bölüme bakınız
ssh-keygen . OpenSSH sertifikalarının biçimi "normal" X.509 sertifikalarından (SSL ile kullanıldığı gibi) çok daha basittir. Sadeleştirmenin de bir bedeli vardır: merkezi bir iptal desteği yoktur. Bunun yerine, özel bir anahtarın güvenliği ihlal edilmişse, yine de ilgili ortak anahtarı tüm sunucularda kara listeye almanız gerekir ve kara liste OpenSSH'de beyaz liste (seçenek
AuthorizedPrincipalsFile
sshd_config) normalde
root kontrolü altındadır. Bu nedenle iptal işlemi iyi sonuç vermez ve bir anahtar oluşturduğunuzda veya kaybettiğinizde, PKI'nın kaldırması gereken tam rahatsızlık olduğunda yine de her sunucudaki şeyleri manuel olarak yapılandırmanız gerekir.
Siz yapabildiniz hala zaman sınırlı anahtarlar oluşturuyorsunuz, çünkü OpenSSH sertifikaları zaman sınırlı anahtarları gömebiliyor. Bu durumda, her müşteri makinesine, örneğin bir hafta için iyi olan bir anahtar verirsiniz. Bir hafta sonra ölen anahtarlar ve sunucular tarafından bilinen bir CA ortak anahtarı ile ana CA iyiliğine sahip olursunuz (istemci havuzuna yeni bir makine eklendiğinde tüm sunucularda herhangi bir şeye basmaya gerek yoktur) ve özel anahtar tehlikeye atılmışsa, hasar "sınırlı" dır, muhtemelen bir haftalık çatlamaya direnecek bir anahtar parolanız olduğu varsayılarak (ancak uzlaşma bir anahtar kaydediciyle düşmanca bir devralma ise bu işe yaramaz). Zaman sınırlı anahtarlar zamanla sıkıcı bir şekilde büyüyebilir ve tüm sunucuların her zaman verilmeyen doğru ayarlanmış bir saate sahip olduğunu varsayarlar (sunucu saati çılgınca kapalı olduğundan ve sıfırlama nedeniyle bir sunucudan kilitlenmek talihsiz olur saat, sunucuya SSH erişimi gerektirir ...).
SSH ile ilgili ek bir sorun, her sunucuya ortak anahtar eklemenin kolay olmasıdır. Bu, bir saldırgan özel bir anahtarın güvenliğini aşması ve bir sunucuya erişim kazanması durumunda bir kez,
.ssh/authorized_keys sunucuya yüklerseniz ve hiçbir iptal işlemi bunu düzeltemez. İptal, doğası gereği, eşzamansız bir süreçtir. Bu nedenle, yeterince sıkı bir hasar kontrolü uygulamamaktadır.
Sertifikalar için SSH desteğinin eksiklikleri göz önüne alındığında, bazı durumlarda tüm sunucular üzerinde bazı yapılandırmalar yapmaktan kaçınan makul bir şema yoktur. Dolayısıyla, yeni bir istemci makinesi eklediğinizde temel olarak aşağıdaki seçenekleriniz vardır:
Özel anahtarı başka bir istemci makineden kopyalarsınız (şu anda yaptığınız şey budur). Bu, sunucular üzerinde fazladan yapılandırma gerektirmez.
Bu makine için yeni bir anahtar çifti oluşturursunuz. Ortak anahtarı tüm sunuculara zorlamanız gerekir.
Anahtar güvenliğinin aşılması durumunda, ilgili ortak anahtarı tüm
.ssh/authorized_keys. Bu kaçınılmazdır (önlemek için sertifika kullanmanız gerekir ve SSH sertifikalarda iyi değildir, yukarıya bakın). Daha sonra, if seçim 1'i kullandıysanız, ayrıca yeni bir anahtar çifti oluşturmanız ve tüm istemci = güvenliği ihlal edilmiş özel anahtarın bir kopyasını kullanan makineler.
Bu nedenle, seçim 1 normal durumda seçim 2'den daha az yapılandırma çalışması gerektirir, ancak önemli bir uzlaşma meydana geldiğinde işler tersine çevrilir. Uzlaşmalar normalde nadir olaylar olduğundan, bu seçenek 1'i tercih eder (zaten yaptığınız şeydir). Bu yüzden özel anahtarınızı güçlü bir parola ile korumanızı ve tüm istemci sistemlerinize kopyalamanızı öneririm.
Not: Yukarıdakilerin hepsinde, SSH'li bir sunucu listesine bağlanmak istediğinizi ve sunucuların herhangi birine erişmek istediğinizi varsaydım istemci makinelerinizden. Belirli bir sunucuya yalnızca bir veya iki belirli istemci makineden erişmek gibi erişimi kısıtlamak istersiniz might. Bu, birden fazla istemci anahtarıyla yapılabilir, ancak yapılandırma karmaşıklığı karesel olarak artar.
Temelde anahtar çiftlerle başa çıkmak için kişisel bir strateji geliştirmeye çalışıyorum
Öncelikle söz konusu sunuculardan sorumluysanız, kukla/şef gibi yapılandırma yönetimi araçlarını aramanızı şiddetle tavsiye ederim. Her ikisinde de SSH anahtarlarını makinelerinize dağıtma yöntemleri vardır.
Kukla kullanmaya başlamamın nedenleri, personel değiştiğinde ~ 60 Linux sunucumda hızlı bir şekilde bir anahtarı iptal etmek için iyi bir yol istememdi.
Anahtarlarınızı yönetmek için bir yapılandırma yönetim aracınız olduğunda, birçok anahtar çiftine sahip olmak çok daha kolay hale gelir. Her kutuda bir anahtarı el ile iptal etmek veya her kutuya yeni bir anahtar eklemek yerine, yapılandırma anahtarına genel anahtarı eklemeniz yeterlidir ve istemciler yapılandırma yönetiminiz için belirlediğiniz yoklama aralığı içinde yetkilendirme listelerini güncelleyecektir aracı.
Bu, yapılandırma yönetimi Ana Bilgisayarınızdan taviz verilmemesi konusunda çok güven duyduğunuz anlamına gelir. Genellikle yapılandırdığınız her makinede kök ayrıcalıkları olan görevleri gerçekleştirdiğinden, çok sayıda denetim ile sıkıca kilitlendiğinden emin olmalısınız. Bir saldırgan yapılandırma yöneticisinin güvenliğini aşacaksa, yeni anahtar ekleme, yeni hesap ekleme vb. Gibi her şeyi yapabilir.
Alem ve makine başına bir anahtar kullanıyorum. 2 iş istasyonundan erişilen 4 uzaktan kumanda => 8 özel anahtar. Özel anahtarı asla Ana Bilgisayardan başkasına kopyalamayın. Bir iş istasyonundan ödün verilirse, tüm bu anahtarları iptal edin.
Anahtarlar oluşturmak ve bunları kullanmak için SSH'yi yapılandırmak oldukça sıkıcı olduğundan, Github erişimi için SSH anahtarlarımı yönetmeye adanmış bir araç yazdım: github-keygen .