Czy można skonfigurować `sudo` bez hasła na serwerze w chmurze?

Podoba mi się pomysł uzyskiwania dostępu do serwerów za pomocą kluczy, dzięki czemu nie muszę wpisywać hasła za każdym razem, gdy jestem sshw skrzynce, a nawet blokuję hasło (nie root) użytkownika ( passwd -l username), więc niemożliwe jest zalogowanie się bez klucza.

Wszystko to psuje się, jeśli muszę podać hasło do sudopoleceń. Kusi mnie więc, aby skonfigurować hasło bez hasła,sudo aby było zgodne z logowaniem bez hasła.

Jednak wciąż mam przeczucie, że może mnie to rzucić w nieoczekiwany sposób, po prostu wydaje się niepewne. Czy są jakieś zastrzeżenia przy takiej konfiguracji? Czy poleciłbyś / nie zaleciłbyś zrobienia tego dla konta użytkownika na serwerze?

Wyjaśnienia

1. Mówię tutaj o użyciu sudow interaktywnej sesji użytkownika, a nie w usługach i skryptach administracyjnych
2. Mówię o korzystaniu z serwera w chmurze (więc nie mam fizycznego lokalnego dostępu do komputera i mogę się logować tylko zdalnie)
3. Wiem, że sudoupłynął limit czasu, w trakcie którego nie muszę ponownie wprowadzać hasła. Ale mój koncert nie polega na marnowaniu dodatkowego czasu na fizyczne wpisanie hasła. Moim pomysłem było jednak wcale nie mieć do czynienia z hasłem, ponieważ zakładam, że:
   • Jeśli w ogóle muszę to zapamiętać, jest bardzo prawdopodobne, że jest za krótki, aby go zabezpieczyć lub ponownie wykorzystać
   • Jeśli wygeneruję długie i unikalne hasło do mojego zdalnego konta, będę musiał je gdzieś przechowywać (lokalny program do zarządzania hasłami lub usługa w chmurze) i pobierać za każdym razem, gdy będę chciał z niego skorzystać sudo. Miałem nadzieję, że uda mi się tego uniknąć.

Tak więc z tym pytaniem chciałem lepiej zrozumieć ryzyko, zastrzeżenia i kompromisy jednej możliwej konfiguracji w stosunku do innych.

Kontynuacja 1

Wszystkie odpowiedzi mówią, że brak hasła sudojest niepewny, ponieważ pozwala na „łatwą” eskalację uprawnień, jeśli moje osobiste konto użytkownika zostanie naruszone. Rozumiem, że. Ale z drugiej strony, jeśli użyję hasła, ponosimy wszystkie klasyczne ryzyko związane z hasłami (zbyt krótki lub wspólny ciąg, powtarzany w różnych usługach itp.). Ale sądzę, że jeśli wyłączę uwierzytelnianie hasła /etc/ssh/sshd_config, aby nadal mieć klucz do zalogowania, mogę użyć prostszego hasła, sudoaby łatwiej było je wpisać? Czy to ważna strategia?

Kontynuacja 2

Jeśli mam również klucz do zalogowania się za rootpośrednictwem ssh, jeśli ktoś uzyska dostęp do mojego komputera i ukradnie moje klucze (choć nadal są chronione hasłem klucza systemu operacyjnego!), Równie dobrze może uzyskać bezpośredni dostęp do rootkonta , omijając sudościeżkę. Jakie powinny być zasady dostępu do rootkonta?

Podoba mi się pomysł uzyskiwania dostępu do serwerów za pomocą kluczy, aby nie musiałem wpisywać hasła za każdym razem, gdy ssh do skrzynki, nawet blokuję hasło użytkownika (nie root) (passwd -l nazwa użytkownika), więc niemożliwe jest zaloguj się bez klucza ... Czy poleciłbyś / nie zaleciłbyś zrobienia tego dla konta użytkownika na serwerze?

Zamierzasz wyłączyć logowanie oparte na hasłach w niewłaściwy sposób. Zamiast blokować konto użytkownika, ustaw PasswordAuthentication nona swoim /etc/ssh/sshd_config.

Przy takim zestawie uwierzytelnianie hasła jest wyłączone dla ssh, ale nadal możesz używać hasła do sudo.

Tylko raz zalecamy ustawienie NOPASSWDw sudo jest dla kont usług, w których procesy muszą być w stanie uruchomić poprzez polecenia sudo programowo. W takich okolicznościach upewnij się, że umieściłeś na białej liście tylko określone polecenia, które konto musi uruchomić. W przypadku kont interaktywnych zawsze należy pozostawiać włączone hasła.

Odpowiedzi na pytania uzupełniające:

Ale myślę, że jeśli wyłączę uwierzytelnianie hasła w / etc / ssh / sshd_config, aby nadal mieć klucz do zalogowania, mogę użyć prostszego hasła tylko dla sudo, które łatwiej wpisać? Czy to ważna strategia?

Tak, to jest poprawne. Nadal zalecam używanie stosunkowo silnych haseł do kont lokalnych, ale nie absurdalnie silnych. ~ 8 znaków, losowo wygenerowanych wystarczy.

Jeśli mam również klucz do zalogowania się jako root za pośrednictwem ssh, jeśli ktoś uzyska dostęp do mojego komputera i ukradnie moje klucze (mimo to nadal są chronione hasłem klucza systemu operacyjnego!), Równie dobrze mogą uzyskać bezpośredni dostęp do konto root, omijając ścieżkę sudo.

Dostęp root poprzez ssh powinien być wyłączony. Kropka. Ustaw PermitRootLogin now swoim sshd_config.

Jakie powinny być zasady dostępu do konta roota?

Zawsze powinieneś mieć możliwość uzyskania pozapasmowego dostępu do konsoli swojego serwera. Zapewnia to kilku dostawców VPS, podobnie jak dostawcy dedykowanego sprzętu. Jeśli Twój dostawca nie przyznaje rzeczywistego dostępu do konsoli (na przykład EC2), zazwyczaj możesz przywrócić dostęp, korzystając z procesu podobnego do tego, który zarysowuję w tej odpowiedzi .

Zasadniczo ograniczam użycie NOPASSWORDdo poleceń uruchamianych przez zautomatyzowany proces. Zalecane jest posiadanie konta usługi dla tych poleceń i ograniczenie korzystania z sudo do wymaganych poleceń.

Zezwalanie NOPASSWORDna ogólne polecenia pozwala każdemu, kto uzyska dostęp do Twojego identyfikatora użytkownika, na uruchamianie dowolnych poleceń. Może to wynikać z kompromisu w zakresie twoich danych uwierzytelniających, ale może być tak proste, jak ktoś siedzący przy biurku, gdy odsuniesz się na sekundę.

Uważam, że nie muszę tak często wpisywać hasła. Po wprowadzeniu hasła możesz uruchomić kilka poleceń, jeśli nie zwlekasz między nimi zbyt długo. Limit czasu można konfigurować.

Użyłbym tego tylko w dwóch okolicznościach:

• Gdy jest to absolutnie wymagane w przypadku automatycznego skryptu działającego jako określony użytkownik
• Dla określonych zadań administracyjnych (tylko do odczytu, zadań administracyjnych, a nie tych, które podejmują działania w celu zmiany systemu), a następnie oczywiście tylko dla określonych użytkowników

Domyślnie większość sudokonfiguracji nie pyta cię jeszcze przez chwilę w tej samej sesji (jeśli otworzysz nową powłokę, która nie ma żadnego efektu). Możesz kontrolować to zachowanie do pewnego stopnia za pomocą tego timestamp_timeoutustawienia.

Bez hasła nie sudojest prawie tak niebezpieczne, jak sshklucze bez hasła , ponieważ zdalny atakujący potrzebuje twoich danych uwierzytelniających, aby dostać się do niego, ale jeśli dostał się, w jakiś sposób naruszając twój klucz prywatny (lub jeśli fizycznie są dla ciebie lokalnie i pozostawiłeś się zalogowany i odblokowany, gdy jesteś z dala od komputera), wtedy prośba o hasło stanowi cenną dodatkową ochronę między nimi a uprzywilejowanym dostępem.

W odniesieniu do działań następczych 2:

Jeśli mam również klucz do zalogowania się jako root przez ssh

Najlepiej tego też unikać, właśnie z tego powodu, który opisujesz. Jeśli zdalne połączenie musi mieć uprzywilejowany dostęp, zaloguj się za pośrednictwem konta usługi i daj mu wystarczającą kontrolę, aby wykonywać swoje zadanie za pośrednictwem sudo. Jest to bardziej fajne do skonfigurowania, więc tak wielu nie przejmuje się (co działa na twoją korzyść, jeśli to zrobisz, ponieważ jest dużo niższych wiszących owoców niż ty, dla atakujących, aby spędzić tam czas!), Więc sprowadza się to do odwieczny kompromis między bezpieczeństwem a wygodą (wskazówka: wybierz bezpieczeństwo!).

Możesz mieć to, co najlepsze z obu światów: uwierzytelnianie SSH zarówno przy logowaniu, jak i sudo. Jeśli zintegrujesz moduł pam_ssh_agent_auth , możesz użyć kluczy SSH do uwierzytelnienia bez podawania hasła podczas sudo.

Używam tego w produkcji od ponad pięciu lat.

Aby go skonfigurować, zainstaluj moduł PAM, a następnie dodaj linię /etc/pam.d/sudolub ekwiwalent systemu:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

Jeśli to zrobisz, pamiętaj, aby zabezpieczyć klucze na komputerze za pomocą hasła. W ten sposób ktoś musiałby włamać się do komputera i ukraść klucze, aby się do niego dostać. Mógłby to zrobić, wyciągając je z pamięci, gdy były odblokowane, jeśli mają dostęp do twojego konta, łamiąc twoje hasło lub kradnąc twoje hasło keylogger lub ramię surfujące po nim podczas pisania (patrz za siebie!).

Możesz użyć tego samego klucza SSH co podczas logowania lub możesz ustawić osobny klucz, który dodajesz do swojego agenta tylko podczas sudo. Jeśli więc chcesz zachować szczególną ostrożność, możesz zachować osobny plik kluczy autoryzowanych, który ma osobny klucz SSH, który dodajesz do swojego agenta tylko wtedy, gdy potrzebujesz sudo:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

Ponieważ pytałeś, oto moja ogólna rada, jak rozwiązać ten sudoproblem.

Sudo nie zostało zaprojektowane w celu zapewnienia większego bezpieczeństwa (choć w pewnym sensie może) ... ale raczej zapewnia dobrą ścieżkę audytu tego, kto robi to, co w twoim systemie i jakie uprawnienia.

Prawidłowo skonfigurowane Sudo nie będzie korzystało z tego ALL=(ALL) ALLustawienia, a raczej z czegoś bardziej ograniczonego do tego, czego konkretnie potrzebuje użytkownik. Na przykład, jeśli potrzebujesz użytkownika, aby móc się zalogować i ponownie uruchomić zablokowaną usługę, prawdopodobnie nie potrzebuje ona możliwości instalowania nowego oprogramowania lub zamykania serwera, zmiany reguł zapory itp.

Czasami ludzie używają sudo, aby dostać się na konto root, tj. sudo su -. Gdy to zrobią, przestaniesz widzieć, kto robi to, co robi z konta root (root może być zalogowany wiele razy jednocześnie). Czasami więc ludzie również chcą wyłączyć sudo su -polecenie. Ale ze względów praktycznych, jeśli potrzebujesz konta w pełni uprzywilejowanego do rootowania do administrowania, przynajmniej wydanie sudo su -komendy spowoduje zapisanie, kto i kiedy został rootowany.

Jak zabezpieczam swoje pudełka:

Zmień port SSH na inny niż domyślny. Ma to na celu uniknięcie głupich botów, które szukają numerów portów, a następnie walą, dopóki nie wejdą (lub nie).

Nie zezwalaj na rootowanie przez SSH przy użyciu AllowRootLogin noustawienia z twojego sshd_config. Zapobiega to brutalnemu wtargnięciu na twoje konto root. Zasadniczo dobrą praktyką jest, aby nigdy nie zezwalać komukolwiek na bezpośrednie logowanie się do konta root / administratora ze względów kontrolnych i bezpieczeństwa. Jeśli zezwalasz na bezpośrednie logowanie do konta root, nie wiesz, kto się zalogował, od kogo dostał hasło itp. Ale jeśli ktoś zaloguje się na konto Jimmy'ego, to zwiększy swoje uprawnienia do rootowania, masz lepszy pomysł, od czego zacząć wyszukiwanie audytu (i kto ma konto zresetować).

Zezwalaj tylko użytkownikom na SSH, którzy tego wymagają. W AllowUsersustawieniach i szczegółowości określ, które konta wymagają dostępu do SSH. Spowoduje to domyślnie zablokowanie wszystkich innych kont z SSH.

Edytuj sudoery za pomocą visudo i zezwalaj tylko na polecenia potrzebne użytkownikowi. Istnieje wiele szczegółowych poradników, jak to zrobić, więc nie będę tutaj szczegółowo opisywał. Oto starter: http://ubuntuforums.org/showthread.php?t=1132821

Istotą tego jest zapobieganie zagrożeniu konta przez zainfekowane konto. to znaczy. jeśli konto Sally zostanie włamane, a Sally może używać sudo tylko do ponownego uruchomienia serwera WWW, atakujący może dobrze się bawić, uruchamiając ponownie serwer WWW w pętli, ale przynajmniej nie może rm -rf /your/webserver/directoryotworzyć wszystkich portów zapory itp.

Skonfiguruj dobre reguły zapory, które zezwalają tylko na porty niezbędne do działania twojego urządzenia. Zasadniczo chcesz porzucić wszystko i zezwalaj tylko wyraźnie na to, czego potrzebujesz. Jest mnóstwo przyzwoitych iptables i innych zapór sieciowych, które uruchamiam online, oto jeden, którego używam (to podstawowy starter):

# Generated by iptables-save v1.4.7 on Mon Mar  3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar  3 17:55:02 2014

Kluczem jest także silne hasło.Nawet jeśli używasz kluczy SSH do zdalnego dostępu, nadal potrzebujesz hasła do korzystania z Sudo. Jest to przypadek, w którym sudo może zapewnić większe bezpieczeństwo. Jeśli ktoś ukradnie twoje klucze ssh, nadal nie będzie mógł zrobić nic znaczącego na twoim pudełku, jeśli będzie musiał brutalnie wymusić hasło do konta, aby użyć sudo. Hasła nie powinny być słowem, ale raczej frazą hasła. Pomyśl o zdaniu i użyj go. To na ogół da ci coś więcej niż 8 znaków, zapewniając mnóstwo entropii, ale także jest łatwiejsze do zapamiętania niż jakieś losowe hasło. Oczywiście, dobre praktyki dotyczące haseł mówią, że używają losowego hasła generowanego przez maszynę, aby oszukać narzędzia do łamania zabezpieczeń, takie jak John the Ripper, który rozdziera większość haseł i haseł. Nie, zmiana E na 3 nie działa, John też dostaje te permutacje.

W niektórych przypadkach należy to zrobić. np. niektóre interfejsy API hypervisor wymagają logowania bez hasła i hasła sudo. Ale nadal możesz to ograniczyć bez zerwania.

Za to, co próbujesz osiągnąć. Powiedziałbym, przyzwyczaj się do wpisywania hasła. Bezpieczeństwo jest tutaj wygodniejsze niż wygoda. Poza tym, jeśli naprawdę potrzebujesz dostępu do roota, możesz go użyć sudoi buforuje on poświadczenia przez chwilę, więc jeśli uruchomisz kilka poleceń sudo z rzędu, poprosi tylko o hasło za pierwszym razem. Więc nie jest to tak duża niedogodność, jak przypuszczasz.

Także jeśli piszesz w wielu korzeniowych uprzywilejowanych poleceń i nie chcesz umieścić na sudo przed nimi cały czas, co możliwe, albo suczy sudo -saby uzyskać powłokę root. Podasz hasło raz, a potem to wszystko.

Raz ugryzł mnie sudo bez hasła. To był skrypt powłoki, jakiś instalator, który wywołał sudo w moim imieniu w przeciwieństwie do, no wiesz, po prostu wymagającego sudo lub błędu.

Obrazowanie wpisując „make” i skrypt wykonujący część „sudo make install” dla Ciebie, bez ustawiania ani wyświetlania ścieżki bazowej, a skrypt jest tak braindeadem, że nie jesteś pewien, że wiedzą o / usr / local i zaczynasz sprawdzać / usr pod kątem modyfikacji ...

Przysięgałem, że nigdy więcej nie użyję NOPASSWD, a także zmieniłem ustawienie limitu czasu na 0.

Nie odpowiadając ściśle na twoje pytanie, inną opcją może być ustawienie dłuższego timestamp_timeout, abyś nie musiał tak często wpisywać hasła. Zapobiegnie to zdobyciu uprawnień administratora, ale zmniejszy irytację.

Ze strony podręcznika sudoers :

timestamp_timeout

Liczba minut, które mogą upłynąć, zanim sudo poprosi ponownie o hasło. Limit czasu może obejmować element ułamkowy, jeśli drobna ziarnistość jest niewystarczająca, na przykład 2,5. Wartość domyślna to 5. Ustaw tę wartość na 0, aby zawsze monitować o hasło. Jeśli zostanie ustawiona wartość mniejsza niż 0, znacznik czasu użytkownika nigdy nie wygasa. Można to wykorzystać, aby umożliwić użytkownikom tworzenie lub usuwanie własnych znaczników czasu za pomocą odpowiednio „sudo -v” i „sudo -k”.

W tym poście na blogu pokazano kilka przykładów użycia visudoustawienia limitu czasu w minutach, takich jak:

Defaults timestamp_timeout=60

Może to jest szczęśliwy środek między bezpieczeństwem a łatwością użytkowania?

Inne odpowiedzi tutaj są świetne i dotyczą większości ważnych punktów. Jedną rzeczą, o której nie wspomniałem, jest fakt, że każde uwierzytelnienie, które wykonujesz po zalogowaniu się, może zostać przechwycone przez zdalnego atakującego, który już ustanowił przyczółek na twoim koncie. Mogą modyfikować pliki logowania powłoki lub ŚCIEŻKĘ, aby zainstalować keylogger, aby wszystko, co wpiszesz, w tym hasło sudo, zostało do nich wysłane. Mogą dodać zhakowany plik binarny sudo do ŚCIEŻKI, aby zebrać hasło. Mogą przejąć połączenie agenta ssh z powrotem na maszynę łączącą, aby pokonać pam_ssh_agent_auth i zostać rootem, gdy tylko się połączysz. Więc jeśli chodzi o absolutne bezpieczeństwo, nie widzę różnicy między używaniem hasła do sudo, a nie. To oczywiście czyni go bardziej skomplikowanym atakiem,

Podsumowując, uważam, że jedynym sposobem, aby absolutnie zapobiec przejęciu konta użytkownika z dostępem roota, jeśli masz dostęp do sudo, jest usunięcie dostępu sudo z ciebie lub nigdy z niego nie korzystaj. Jeśli się nie zgadzasz, daj mi znać, ponieważ chciałbym się mylić!