SSH için neden Genel Anahtar Kimlik Doğrulaması kullanmalıyım?

Bir SSH sunucusu çalıştırıyorum ve hala basit bir şifre doğrulama kullanıyorum. Güvenlik hakkında okuduğum her yerde Açık Anahtar Kimlik Doğrulaması kullanmam önerilir. Ama ben avantajları alamıyorum. Bunları kullanmak gözlerime güvensiz ya da çok fazla kullanışlı iş.

Tabii ki, birisi kaba kuvvetle SSH sunucuma giriş yapmayı denerse, Açık Anahtar herhangi bir şifreden çok daha güçlüdür. Ama bunun dışında, tamamen güvensiz.

Danışmanlar çoğunlukla bir şifreyi hatırlamanız gerekmediğini savunur. Bu ne kadar güvensiz? Yani birisi bilgisayarıma girerse, bilgisayarımı almaz, sunucumu da alır. SSH'yi farklı istemcilerden kullanıyorsam, genel anahtarları her biri için ayrı ayrı saklamam gerekiyor, bu da yanlış ellere düşme ihtimalini arttırıyor. Onları yanımda taşıdığım bir usb belleğe kaydedebilirim, ancak kaybolabilir ve bulucu sunucuma erişebilir.

Muhtemelen, İki Faktörlü Kimlik Doğrulama ile daha iyi bilgilenirim.

Kaybettiğim bir tartışma var mı? Benim için en iyi yol nedir?

Birisi bilgisayarıma girerse, bilgisayarımı değil, sunucumu da alır.

Bu, keylogger'larla zaten potansiyel olarak doğrudur: Sunucunuza tehlike altındaki bilgisayardan giriş yaptığınız anda, şifreyi alırlar.

Ancak anahtarların 3 avantajı vardır:

1) Önbelleklenebilir kimlik doğrulama. Parolanızı bir kez girin, birden fazla ssh komutu uygulayın. Scp, rsync veya git gibi ssh'yi bir aktarım olarak kullanan bir şey kullanıyorsanız bu çok kullanışlıdır.

2) Ölçeklenebilir kimlik doğrulama. Parolanızı bir kez girin, birden fazla makineye giriş yapın . Ne kadar çok makineye sahipseniz, o kadar faydalı olur. 100 makinen varsa, ne yaparsın? Aynı şifreyi kullanamazsınız (bir klon çiftliği olmadığı sürece) ve o kadarını hatırlayamazsınız. Yani bir şifre yöneticisi kullanmak zorunda kalacaksınız ve tek bir uzlaşma noktasına geri döneceksiniz. Etkili anahtar parola olduğu için şifre yöneticisi.

2b) Aynı sistemleri kullanan birden fazla yöneticiniz varsa, diğer şekilde ölçeklendirilir, çünkü B, C, D, E, F ... şifrelerinin değiştiğini söylemek zorunda kalmadan A kullanıcısından anahtarları iptal edebilirsiniz.

(Bu bireysel hesaplar ve sudo ile de yapılabilir, ancak daha sonra bu hesapları bir şekilde sağlamanız gerekir)

3) Otomasyon ve kısmi delegasyon. Bir anahtar bağlandığında SSH'yi belirli bir komutu çalıştırmak için ayarlayabilirsiniz . Bu, sistem A'daki otomatik bir işlemin, ikisi arasında tam şifresiz güven duymadan, B sisteminde bir şey yapmasını sağlar.

(Çok komik bir şekilde güvensiz olan rlogin / rsh'nin yerine geçmiştir)

Düzenleme: şifreler yerine genel anahtarların başka bir avantajı, sunucunun bir güvenlik açığından etkilendiği ortak senaryodur. Bu durumda, bir şifre ile giriş yapmak, şifreyi derhal tehlikeye atar. Bir anahtarla giriş yapmayın! Bunun yöneticinin menşei masaüstünden ödün vermeden daha yaygın olduğunu söyleyebilirim.

İyi şifreler kullanıyorsanız, bu yeterince güvenli olabilir. Genel olarak herkesin erişebileceği sunucu sayısını en aza indirir ve mümkün olduğunda belirli IP'lerden SSH'ye izin veririm.

Ayrıca, anahtarlarınızı parola (şifre) ile koruyabilirsiniz. Bu nedenle, sunucularınıza giriş yapmak istediğinizde bu parolanın girilmesi gerekir. Doğru parola sağlanmadıkça kimse anahtarınızı kullanamaz.

Benzer mesajlar var:

1. Serverfault adresinden gönder .
2. Dan yayınla güvenlik Stack Exchange .
3. Süper kullanıcıdan yayınla .

Genel anahtar yetkilendirmesinin daha güvenli olduğu bir yol, saldırganın istemci bilgisayarınızla sunucu arasında ortadaki adam (MitM) olmayı başarmasıdır ve değişen ana bilgisayar anahtarını fark etmiyorsunuzdur (muhtemelen eski anahtara sahip değil, örneğin bu özel istemci bilgisayarı ilk kez kullandığı için).

(Aynı, saldırgan sunucuyu kontrol altına almayı başardığında ve aynı kimlik bilgilerinin çalıştığı başka sunucular olduğunda da geçerlidir.)

Standart parola tabanlı kimlik doğrulamasıyla, parolanızı (şifreli bağlantının içinde) düz metin olarak gönderirsiniz, orijinal sunucu normalde karma kullanır ve sonucu parola veritabanında depolanan karma ile karşılaştırır. Bir MitM saldırganı bu şifreyi alabilir, gerçek sunucuya bir bağlantı açabilir ve orada oturum açabilir ... ve içeriği size ileterek (hiçbir şey farketmezsiniz) ya da sadece sunucunuzda kendi kötü şeylerini yapabilir .

Genel anahtar kimlik doğrulaması ile istemci, temelde hem özel anahtara sahip olduğunu kanıtlamak amacıyla hem sunucu hem de müşteri tarafından bilinen bazı verileri imzalar ve imzayı sunucuya gönderir. Bu imzalı veriler, hem istemci hem de sunucu tarafından seçilen rasgele sayılara bağlı olan ve bu nedenle her oturum için farklı olan bir oturum tanımlayıcısı içerir. MitM, gerçek sunucuya kendi SSH bağlantısını açarsa, bu kişinin farklı bir oturum kimliği olacaktır ve bu nedenle müşteri tarafından sağlanan imza orada çalışmayacaktır.

Elbette, daha önce söylenmiş diğer cevaplar gibi, özel anahtarınızı güvende tutmalısınız, örneğin bir şifre ile şifrelenmiş ya da sadece bir PIN girdikten sonra imza oluşturan ayrı bir cihazda mümkün.

OpenSSH, SSH ana bilgisayarını ve istemci anahtarlarını yönetmek için kendi CA'sını saklayabilir ve üzerlerindeki iptal listelerini kullanabilir. Bu, anahtar tabanlı kimlik doğrulaması tarafından sağlanan güvenliğe katkıda bulunabilir.

"Parolaya ihtiyacın yok" iddiasında haklısın. Bu müşteri tarafında gerçekten güvensiz.

Oturum açmak için yalnızca genel anahtarların daha güvenli şekilde oturum açmasına izin veren şey, sunucunuza zorla erişim sağlamanın mümkün olmamasıdır. Saldırganın başarabileceği tek şey sunucunuza bir miktar yük koymaktır - bunu kontrol altında tutmak için fail2ban'ı kullanabilirsiniz.

Müşteri tarafında güvenlik için, özel anahtarı iyi bir parola ile korumalısınız. Tabii ki şimdi sunucuya bağlanmak bir şifre ile daha hantal. Bunun üstesinden gelmek için, arka arkaya birkaç kez sunucuya bağlanmak istiyorsanız, özel anahtarı bellekte saklamak için ssh aracısını kullanabilirsiniz . Bir anahtarın bellekte ne kadar süreyle saklanacağı süresinin sınırlandırılması iyi bir uygulamadır.

Muhtemelen, İki Faktörlü Kimlik Doğrulama ile daha iyi bilgilenirim.

SSH için 2FA için bir olasılık (ve nispeten az kurulum / karmaşıklık gerektiren bir olasılık) aslında bir ortak anahtar ve şifre kullanmaktır.

Bu işi yapmak için satır boyunca bir şeyler AuthenticationMethods publickey,keyboard-interactiveeklenebileceğine inanıyorum /etc/ssh/sshd_config.

Daha genel olarak, sorun, parolaların (yalnız başına) kimlik doğrulama için harika bir yöntem olmadığından daha fazla sorun yaratmasıdır. Anahtarlar ve şifreler için çok basit bir 'argüman', bir anahtarın genellikle en az 2048 bit ve genellikle daha fazla olacağıdır (EC anahtarları için bu, gerçek boyuttan ziyade etkin güç olacaktır). Bu bitler ayrıca kriptolojik olarak güvenli (veya uygun) bir mekanizma tarafından da üretilir.

Bir şifre genellikle 2048 bitin altındadır ve çoğu zaman kriptografik olarak güvenli bir kaynaktan türetilmez.

Ayrıca, birisini kaybetmekle ilgili sorunlara karşı korunmak için bir şifre ile güvence altına alabilirsiniz (birileri bu şifreyi zorlayabilmeye çalışsa da).

Dolayısıyla temel olarak, anahtarlar ve şifreler arasındaki farklar oldukça şeffaf hale getirilebilir ve anahtarların kullanılması size bir insanın baş edebileceğinden daha iyi bir şifre getirir. Bu onların her derde deva olduğu anlamına gelmez, ancak ortalama olarak, şifrelerden daha fazla güvenlik sağlarlar.