Czy centralna lokalizacja dla kluczy autoryzowanych to dobry pomysł?

Jestem w trakcie konfigurowania serwera w chmurze do uruchamiania następującego stosu: Ruby, Passenger, Apache; pod Ubuntu 10.04 (Lucid Lynx).

Chcąc ułatwić zarządzanie serwerem, konfiguruję klucze RSA rooti www-datamogę sshwejść na serwer. To, co się nie podoba to, że www-datajest .sshkatalog siedział w /var/wwwktórym jest domyślny katalog instalacyjny dla apache. Martwię się, że jeśli apache nie zostanie poprawnie skonfigurowany, .sshkatalog może zostać ujawniony.

Natknąłem się na rozwiązanie, aby przenieść ~/.ssh/authorized_keysplik do centralnej lokalizacji, zmieniając AuthorizedKeysFilesię /etc/ssh/sshd_config. Zawiera 2 zalety: jedną lokalizację dla kluczy i nie musisz się martwić o złą konfigurację apache. Jedynym oszustwem, o którym myślę, jest to, że teraz każdy użytkownik jest dostępny do logowania na serwerze (wyraźnie obosieczny miecz centralnego pliku klucza).

Czy jest coś, czego mi brakowało w tej konfiguracji? Czy sam się naraziłem, czy jest to lepsze rozwiązanie niż pojedyncze authorized_keyspliki?

Jestem zielony, jeśli chodzi o zarządzanie serwerami, ale jestem całkowicie gotowy nazywać się złymi nazwiskami za robienie złych rzeczy. :RE

— Gavin Miller
źródło

Przynajmniej ujawnienie kluczy publicznych (tylko do odczytu) w Internecie nie stanowi największego ryzyka ... (Może to pozwolić atakującym sprawdzić, czy mogą zalogować się do serwera za pomocą klucza prywatnego, który uzyskali gdzie indziej, ale nie nie zezwalaj im na logowanie się po prostu poprzez uzyskanie tego ...) (Poważne problemy dotyczą tego, że istnieje id_rsaplik ~/.sshi uda się go odczytać)

— Gert van den Berg

Odpowiedzi:

Wszystkie pliki kluczy można scentralizować w tym samym katalogu i nie mieszać w tym samym pliku.

Po prostu skonfiguruj sshd_configplik w ten sposób:

AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Na twoim serwerze:

Klucze www-data będą włączone /etc/ssh/authorized_keys/www-data
klucze root będą w /etc/ssh/authorized_keys/root

Jeśli chodzi o prawa dostępu, te ustawienia są akceptowane przez sshd:

/etc/ssh/authorized_keysjest własnością root:rooti ma tryb 755. Pliki kluczy są własnością root:rooti mają tryb 644.

Inne tryby mogą działać, ale ich nie testowałem.

— mahn
źródło

+1, ale nie ustawiłbym innych. Ustaw własność plików% u na użytkownika, aby nie było to konieczne.

— Aaron Copley,

Dobre rozwiązanie problemu polegającego na tym, że złośliwi użytkownicy mogą dodawać więcej kluczy publicznych do swoich ~ / .ssh / uprawnionych_ kluczy, zapewniając dostęp do innych.

— bbaassssiiee

Właśnie potwierdziłem, że tryb 600 dla pliku autoryzowanych kluczy użytkownika nie działa; musi to być tryb 644

— Luis E.

@bbaassssiiee To absolutnie NIE rozwiązuje tego problemu. Mogą po prostu udostępnić swój klucz prywatny

— komukolwiek, komu

@DylanYoung Przyznaję, że udostępnianie kluczy prywatnych jest możliwe. Ale dzięki chattr mogę cofnąć dostęp do zapisu do plików autoryzowanych_kluczy, dzięki czemu mogę dystrybuować je wyłącznie, zabezpieczając również jedną linię w każdym pliku.

— bbaassssiiee

Ogólnie rzecz biorąc, nie zrobiłbym tego, co sugerujesz. Łamie typowe założenia (takie jak ~/.ssh/authorized_keyspraca dla użytkowników i wprowadza problemy, o których już wspomniałeś w swoim pytaniu. Jeśli zobaczysz rażące problemy przed wdrożeniem, oznacza to, że twoje rozwiązanie nie jest idealne.

Jeśli chodzi o bezpieczeństwo, myślę też, że POWAŻNY jest pomysł, aby wszyscy mieli wspólne konto usługowe: w tej chwili to tylko Ty i wiesz, że to Ty wprowadzasz zmiany. Za 5 lat, kiedy masz 5 administratorów, będziesz chciał wiedzieć, kto co zmienił, i przeglądając dzienniki kontroli, aby zobaczyć, kto używał tego klucza, gdy jest to królewski ból.
Lepiej jest, aby ludzie logowali się jako sami i używali sudoczegoś podobnego do zwiększania swoich uprawnień i robienia wszystkiego, co powinni.

Jeśli nadal chcesz scentralizować klucze SSH, sugeruję zajrzenie do systemu wdrażania, takiego jak Puppet lub radmind, aby zarządzać authorized_keysplikami / dystrybuować je do odpowiednich ~user/.ssh/katalogów (lub zhackować domowe rozwiązanie, które SCP umieszcza je na miejscu).
Po przejściu na wiele serwerów możesz zajrzeć do łaty klucza publicznego LDAP dla starszych wersji OpenSSH (lub AuthorizedKeysCommanddyrektywy i odpowiedniego skryptu w nowszej wersji OpenSSH), abyś mógł scentralizować użytkowników i nie musiał dystrybuować ich klucze w całej sieci, ale prawdopodobnie będzie to dla ciebie dość daleko.

— voretaq7
źródło

+1 za argument udostępniania. Krótko mówiąc, ponieważ zajęło mi to chwilę, aby uświadomić sobie jego konsekwencje: w ogóle nie powinien istnieć katalog ~ www-data / .ssh, więc przeglądarka internetowa nie może stanowić zagrożenia dla bezpieczeństwa.

— thiton,

Dzięki za opinie! Jeśli dobrze cię rozumiem. Nie powinienem mieć rootani www-datadostępu za pośrednictwem klucza SSH. Czy to prawda?

— Gavin Miller,

Posiadanie ~www-data/.sshkatalogu nie jest straszną rzeczą (przy odpowiednich uprawnieniach nie stanowi to znacznego ryzyka), ale jeśli zamierzasz go używać ~www-data/.ssh, prawdopodobnie lepiej nie mieć swojego katalogu głównego ~www-data(przenieś www-datakatalog główny lub przenieś katalog domowy). Zróżnicowanie użytkowników to większy argument IMHO - wiem, że jeśli się jsmithzaloguję, wiem, że to John Smith. Jeśli zobaczę www-datalogowanie, muszę wykopać więcej, aby dowiedzieć się, kto to był.

— voretaq7

Powodem, dla którego potrzebowałem klucza ssh do danych www, jest to, że używam Beanstalk (narzędzie SCM i wdrażanie) do wdrażania przez SFTP. Czy powinienem następnie utworzyć osobne konto dla Beanstalk do robienia ftp? Jakie byłoby najlepsze rozwiązanie?

— Gavin Miller

Tak jest na większości systemów AuthorizedKeysFilew /etc/ssh/sshd_configdomyślnych produktu %h/.ssh/authorized_keys. Oto %hsymbol zastępczy katalogu domowego. Co powstrzymuje cię przed ustawieniem go na, /some/folder/ssh_keys_by_user/%h/a nawet /root/ssh_keys/%u. Możesz nawet dać odpowiedniemu użytkownikowi prawo zapisu do jego indywidualnego pliku (i tylko jego) połączyć plik ze standardową lokalizacją (z ln -s /root/ssh_keys_by_user/username /home/username/.ssh/authorized_keys) i nie złamać wyżej wymienionych założeń.

— con-f-use