ssh ortak anahtarlarını kullanma riski

Ben sunucu A ve sunucu B (yedek) ve sunucu A içine birileri kırılırsa, bu ben ssh kamu tuşlarını kullanarak şifresiz giriş yapılandırılmış varsa sunucu B girmeye tehlikeli olabilir, eğer ben merak ediyorum?

Ben rsnapshot kurmaya çalışıyorum.

Teşekkürler

Evet, şifresiz SSH anahtarlarıyla ilgili sorunlardan biri budur. A sunucusunda B sunucusuna bağlanmanıza izin veren özel bir anahtar depolarsanız, A sunucusuna erişim kazanmak B sunucusuna etkin bir şekilde erişir (Tersi doğru değildir - B sunucusuna erişim elde etmek, Sunucu A'nın derhal güvenliği, bu yönde şifresiz oturum açmaya izin verecek şekilde ayarlanmış SSH anahtarlarınız olmadığı varsayılır.

Bunu hafifletmek için yapabileceğiniz birkaç şey var:

• İşlemin tam otomatik olması gerekmiyorsa, SSH anahtarlarınıza bir şifre ekleyin. (Bu muhtemelen sizin için işe yaramaz, çünkü bunun bir yedek olduğunu unutmayın)
• Birden fazla makineye kendi hesabınız altında şifresiz girişler için, fiziksel olarak yazdığınız her makine için bir şifre anahtarı oluşturmanızı ve anahtarı kullanırken bellekte saklamak için bir SSH aracısı kullanmanızı öneririm. Aracı yönlendirmesi, her uzak ana bilgisayarda anahtar oluşturmadan ana bilgisayardan ana bilgisayara "atlamanızı" sağlar.
• Otomatik, şifresiz SSH anahtarları için, anahtarın çalıştırabileceği komutları kısıtlamanızı öneririm. Senin içinde authorized_keysdosyanın, sizin her anahtar ile önüne:
  command="<allowed command line here>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

8-9 yıl önce, yüzlerce yerel kullanıcıyla paylaşılan bir kullanıcı ortamında çalıştım ve anahtarlarda şifre politikalarını uygulamaya koymanın bir yolu olmadığından SSH anahtar tabanlı girişler devre dışı bırakıldı. Senaryoyu tam olarak kontrol ettiğiniz sürece, günümüzde SSH anahtarları sadece şifreleri kullanmaktan kesinlikle daha iyidir.

Evet, internetteki çoğu rehber, güvenli bir şekilde çalışmak yerine, şifresiz ssh'nin çalışmasını durdurur. Bu kılavuz , riskleri azaltmak için neler yapılabileceğini göstermek için iyi bir iş çıkarmaktadır. Temel olarak (makaleyi alıntılamak için):

• iş için tek amaçlı bir rol hesabı oluşturun: yani dnssyncher makinedeki bir kullanıcı
• mümkünse, dosyaları root olmak yerine bu kullanıcı tarafından yazılabilir hale getirin
• gerçekten ayrıcalıklı erişime ihtiyaç duyan bitler için, bunu yapmak için bir komut dosyası oluşturun ve sudo kullanın
• parola içermeyen anahtarları kısıtlamak için dosyalarda kullanımı command=ve from=seçenekleriauthorized_keys
• dosya aktarımı yapmak için, alıcı makinede rsync kullanarak bir komut dosyası yazın , böylece uzaktan erişim salt okunur olabilir
• bu, uzak makineden başlatma makinesine geri erişim gerektiği anlamına gelirse, ssh-agentikinci bir parolasız anahtar oluşturmak yerine kullanın

Ssh tuşlarıyla ilgili birkaç sorun var:

Bir anahtarı iptal etmenin merkezi bir yolu yoktur.

Anahtarlarda parola ilkeleri uygulamanın bir yolu yoktur (özel anahtarınız şifrelenir ve eğer öyleyse iyi bir parola ile şifrelenir mi?).

Bunlar kerberosların çözdüğü problemler. Bununla birlikte, diğerlerini tanıtır, yani uygulanması daha karmaşıktır ve dağıtmak ve yönetmek için gerçek bir kullanıcı yönetimi altyapısı gerektirir.

Her durumda, ssh yetkili_anahtarlar morris solucan tipi saldırılara izin vermesine rağmen , yine de .r hizmetlerinden ve telnetten mil (ışık yılı) daha iyidir

Kontrol ettiğim herhangi bir ortamda, hizmet hesapları için mümkün olan en düşük ayrıcalık için her zaman gerçek bir yapıştırıcı oldum.

Bu durumda, uzak sunucudaki kullanıcı hesabının yalnızca küçük, sıkı tanımlanmış yürütülebilir dosyalar kümesini çalıştırmasına izin verilmesini öneriyorum. Bunu yapmak için uzak tarafta ve sudo'da birden fazla hesap kullanabilirsiniz.

Bu durumda bile, hala yerel ayrıcalık yükseltme hatalarına maruz kalırsınız, bu yüzden titiz olun ve güvenlik hatalarını sıkıca takip edin.