Yetkililer için merkezi bir yer iyi bir fikir midir?

Aşağıdaki yığını çalıştırmak için bir bulut sunucusunu yapılandırma sürecindeyim: Ruby, Passenger, Apache; Ubuntu 10.04 (Lucid Lynx) altındadır.

Sunucuyu daha kolay yönetmeyi isteme sürecinde RSA anahtarlarını açıyorum rootve www-databöylece sshsunucuya girebiliyorum . Ben sevmedim şey olmasıydı www-data'ın .sshdizin oturdu /var/wwwhangi apache için varsayılan dizin kurulduğundan. Benim endişem, eğer apache düzgün bir şekilde yapılandırılmadıysa, .sshdizinin gösterilebileceğidir.

Hareket etmeye çözüm üzerinde geldi ~/.ssh/authorized_keysdeğiştirerek merkezi bir konumda dosyayı AuthorizedKeysFileiçinde /etc/ssh/sshd_config. Bu, 2 artıyla geliyor: Anahtarlar için tek bir konum ve kötü bir apache yapılandırması için endişelenmenize gerek yok. Aklıma gelen tek con şimdi her kullanıcının sunucuda oturum açmaya hazır olmasıdır (açıkça merkezi anahtar dosyasının iki ucu keskin kılıç).

Bu yapılandırmada kaçırdığım bir şey var mı? Kendimi fazla maruz bıraktım mı, yoksa bu tek tek authorized_keysdosyalardan daha iyi bir çözüm mü?

Ben yeşil sunucu yönetimi söz konusu olduğunda, ama kötü şeyler yapıyor için kötü isimleri çağrılacak tamamen hazırım. : D

— Gavin Miller
kaynak

En azından internette herkese açık anahtarların gösterilmesi (salt okunur) en büyük risk değil ... (Saldırganların başka yerlerde edindikleri özel bir anahtarla sunucuya giriş yapıp yapamayacaklarını görmelerine izin verebilir, ancak sadece bunu elde ederek giriş yapmalarına izin vermeyin ...) (Ciddi meseleler bir id_rsadosya varsa ~/.sshve bunu okumayı başarırlar)

— Gert van den Berg

Yanıtlar:

Tüm anahtar dosyaları aynı dizinde merkezileştirilebilir ve aynı dosyada karıştırılamaz.

Basitçe sshd_configdosyayı şu şekilde ayarlayın:

AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Sunucunuzda:

www-data anahtarları olacak /etc/ssh/authorized_keys/www-data
kök anahtarlar içeride olacak /etc/ssh/authorized_keys/root

Erişim hakları ile ilgili olarak, bu ayarlar sshd tarafından kabul edilir:

/etc/ssh/authorized_keysaittir root:rootve 755 modu vardır. Anahtar dosyalar aittir.root:root ve 644 modu vardır.

Diğer modlar işe yarayabilir ama ben onları test etmedim.

— mahn
kaynak

+1, ama diğerlerini ayarlamazdım. % U dosyalarının sahipliğini kullanıcıya gerek kalmayacak şekilde ayarlayın.

— Aaron Copley

Kötü niyetli kullanıcıların, başkalarına erişim sağlayan ~ / .ssh / yetkili_ anahtarlarına daha fazla ortak anahtar ekleyebilmesi sorununa iyi bir çözüm.

— bbaassssiiee

Bir kullanıcının yetkilendirilmiş anahtar dosyası için 600 modunun çalışmadığını onayladım; mod 644 olması gerekiyor

— Luis E.

@bbaassssiiee Bu KESİNLİKLE bu sorunu çözmez. Özel anahtarlarını yalnızca erişmek istedikleri kişiyle paylaşabilirler (bu olasılık elbette azaltılabilir, ancak bu cevap onu azaltmak için kesinlikle sıfırdır)

— DylanYoung

@DylanYoung Özel anahtarları paylaşmanın mümkün olduğunu kabul ediyorum. Ancak chattr ile yetkili dosyalarınızı yazma erişimini iptal edebilirim, böylece bunları yalnızca dağıtabilirim, her dosyada tek bir satırı koruyarak.

— bbaassssiiee

Genel olarak, önerdiğin şeyi yapmam. Genel varsayımlara aykırıdır ( ~/.ssh/authorized_keyskullanıcılarınız için çalışmak gibi ve sorunuzda daha önce bahsettiğiniz sorunları ortaya koyar. Uygulamadan önce göze çarpan sorunları görürseniz, çözümünüzün ideal olmadığı anlamına gelir.

Güvenlik açısından Ayrıca herkesin bir hizmet hesabını paylaşmasının KORKUNÇ bir fikir olduğunu düşünüyorum : Şu anda sadece siz ve siz de değişiklik yapan sizsiniz. 5 yöneticiniz olduğunda 5 yıl içinde kimin neyi değiştirdiğini bilmek isteyeceksiniz ve kraliyet acısı olduğunda kimin anahtarını kullandığını görmek için denetim günlüklerini kazın.
İnsanların kendileri gibi giriş sudoyapıp kullanmalarını veya ayrıcalıklarını yükseltmek için benzer şeyler kullanmaları ve yapmaları gerekeni yapmaları daha iyidir .

Hala SSH anahtarlarını merkezileştirmek istiyorsanız , dosyaları uygun dizinlere yönetmek / dağıtmak için Puppet veya radmind gibi bir dağıtım sistemine göz atmanızı öneririm (ya da evde yetişen bir SCP'yi yerine oturtmak için). Birden çok sunucuya genişledikçe , OpenSSH'nin eski sürümleri için LDAP Genel Anahtar düzeltme ekine (veya daha yeni OpenSSH sürümündeki yönergeler ve uygun bir komut dosyası) bakmak isteyebilirsiniz, böylece kullanıcılarınızı merkezileştirebilir ve dağıtmak zorunda kalmazsınız. anahtarları ağınızın her tarafında, ancak bu sizin için yolun oldukça aşağısında olabilir.authorized_keys~user/.ssh/
AuthorizedKeysCommand

— voretaq7
kaynak

Paylaşım argümanı için +1. Kısacası, bunun ne anlama geldiğini anlamam biraz zaman aldı: ~ www-data / .ssh dizini olmamalı, bu yüzden web tarayıcısının güvenlik riski olmamalı.

— thiton

Geri dönüşünüz için teşekkür ederiz! Seni doğru anlıyorsam. Bir ssh anahtarı ile rootne www-dataerişilebilir ne de erişilebilir olmalı , doğru mu?

— Gavin Miller

Bir ~www-data/.sshdizine sahip olmak korkunç bir şey değildir (uygun izinlerle önemli bir risk değildir), ancak eğer kullanacaksanız ~www-data/.sshwebroot'unuzun bulunmaması ~www-data(webroot'u hareket ettirmek veya www-dataana dizini taşımak) olmayabilir . Kullanıcıların farklılaşması daha büyük bir argümandır IMHO - jsmithGiriş yaptığımı görürsem John Smith olduğunu biliyorum. Giriş yaptıysam www-data, kim olduğunu bulmak için daha fazla kazmam gerekir.

— voretaq7

Www-data için bir ssh anahtarına ihtiyacım olmasının nedeni, SFTP üzerinden konuşlandırma yapmak için Beanstalk (SCM ve dağıtım aracı) kullanıyorum. Daha sonra ftp'ing'i yapmak için Beanstalk için ayrı bir hesap oluşturmalı mıyım? Orada en iyi çözüm ne olurdu?

— Gavin Miller

Varsayılan olarak çoğu sistemde olduğu AuthorizedKeysFilegibi . İşte giriş dizini için bir yer tutucudur. Sizi ayarlamanıza veya hatta ayarlamanıza engel olan şey . İlgili kullanıcıya, oradaki kendi dosyasına (ve yalnızca onun) kendi dosyasına yazmasına izin verebilir, bu dosyayı standart konuma (birlikte ) bağlayabilir ve yukarıda belirtilen varsayımları bozmazsınız. /etc/ssh/sshd_config%h/.ssh/authorized_keys%h/some/folder/ssh_keys_by_user/%h//root/ssh_keys/%uln -s /root/ssh_keys_by_user/username /home/username/.ssh/authorized_keys

— con-f-