Sudo od innego użytkownika Ubuntu. Edycja pliku sudoers na Ubuntu i CentOS

Jeśli używasz polecenia sudo okresowo, jestem pewien, że zauważyłeś osobliwość w jego działaniu polegającą na tym, że po pomyślnym wprowadzeniu hasła możesz użyć sudo jeszcze kilka razy, w ogóle nie wpisując hasła. Ale po pewnym czasie polecenie Sudo ponownie zaczyna pytać o hasło.

To zachowanie nie ma nic wspólnego z liczbą poleceń wykonywanych przez sudo, ale ma związek z czasem. Tak, domyślnie sudo nie będzie pytać o hasło przez 15 minut po jego pomyślnej weryfikacji. Po tych 15 minutach sudo poprosi Cię o ponowne wprowadzenie hasła.

Jeśli jednak chcesz, możesz zmienić opisane zachowanie. Aby to zrobić, otwórz plik konfiguracyjny /etc/sudoers za pomocą następującego polecenia:

Sudo wizualizacja

Następnie musisz udać się do linii

Domyślnie env_reset

i dodaj następującą zmienną z nową wartością (pogrubioną czcionką) na końcu tego wiersza:

Domyślnie env_reset ,timestamp_timeout=[nowa wartość]

Pole „[nowa wartość]” należy zastąpić liczbą minut, przez jaką powinna istnieć sesja Sudo. Na przykład użyłem wartości 40.

Jeśli chcesz, aby przy każdym użyciu polecenia sudo pojawiał się monit o podanie hasła, możesz ustawić tę zmienną na 0. A jeśli chcesz, aby sesja Sudo trwała wiecznie, możesz ustawić tę zmienną na -1.

Należy pamiętać, że zdecydowanie odradza się używanie wartości -1 dla danej zmiennej.

hasło sudo

Jak być może zauważyłeś, podczas wprowadzania hasła nie są wyświetlane żadne symbole, nawet zwykłe gwiazdki. Choć nie jest to duży problem, niektórzy użytkownicy z różnych powodów chcą zobaczyć chociaż gwiazdy.

Na szczęście aktywacja odpowiedniego trybu hasła jest dość prosta. Wszystko, co musisz zrobić, to zmienić następujący wiersz w pliku /etc/sudoers:

Domyślnie env_reset

Za linię

Domyślnie env_reset,pwfeedback

Teraz podczas wprowadzania hasła podczas korzystania z narzędzia Sudo będą wyświetlane gwiazdki.

Niektóre ważne opcje poleceń sudo

Oprócz opcji -u (o której mówiliśmy na początku tego artykułu), istnieje kilka innych ważnych opcji poleceń Sudo, o których warto wspomnieć. Niektóre z nich omówimy w tej sekcji.

Opcja -k

Załóżmy, że właśnie uruchomiłeś polecenie za pomocą sudo i wprowadziłeś hasło. Jak wiesz, sudo domyślnie nie będzie pytać o hasło przez następne 15 minut. Załóżmy teraz, że chcesz dać komuś dostęp do swojego terminala bez możliwości korzystania z sudo. Co można zrobić w tym przypadku?

Na szczęście istnieje opcja -k, która umożliwia wymuszenie zakończenia sesji sudo. Oto, co napisano o tym parametrze na stronie podręcznika sudo:

-k, --reset-znacznik czasu

Używany bez polecenia umożliwia zresetowanie ustawień użytkownika zapisanych w pamięci podręcznej. Innymi słowy, przy następnym wywołaniu Sudo zostaniesz poproszony o podanie hasła. Ta opcja nie wymaga hasła i została dodana specjalnie, aby umożliwić użytkownikom usuwanie informacji o uprawnieniach sudo z pliku .logout.

W przypadku użycia w połączeniu z poleceniem lub opcją wymagającą hasła może zostać wyświetlony monit o wprowadzenie hasła, ponieważ ta opcja powoduje ignorowanie przechowywanych w pamięci podręcznej informacji o uprawnieniach Sudo. W rezultacie sudo ponownie poprosi Cię o podanie hasła (jeśli wymaga tego polityka bezpieczeństwa) i nie zaktualizuje informacji o uprawnieniach zapisanych w pamięci podręcznej.

-s opcja

Może się zdarzyć, że w trakcie pracy będziesz musiał uruchomić wiele poleceń wymagających uprawnień roota, a nie będziesz chciał przed każdą z nich wpisywać prefiksu sudo. Ponadto nie będziesz chciał konfigurować czasu trwania sesji sudo, edytując plik konfiguracyjny /etc/sudoers.

W tym przypadku przydatna może okazać się opcja -s. Oto opis tej opcji ze strony podręcznika sudo:

-s, --powłoka

Uruchom powłokę poleceń, której ścieżka binarna jest określona przez zmienną środowiskową SHELL, jeśli taka istnieje, lub powłokę poleceń, której ścieżka binarna jest określona w parametrach konta użytkownika wywołującego. Jeśli zostanie użyte polecenie, zostanie ono przekazane do tej powłoki w celu późniejszego wykonania przy użyciu standardowej opcji -c. Jeśli nie zostanie wydane żadne polecenie, użytkownik uzyska dostęp do działającej interaktywnej powłoki poleceń.

Zatem ten parametr wykonuje następujące czynności:

Uruchamia nową powłokę poleceń, której ścieżka do pliku binarnego jest określona za pomocą zmiennej środowiskowej $SHELL. Jeżeli zmienna środowiskowa $SHELL jest pusta, uruchamiana jest powłoka poleceń, której ścieżka do pliku binarnego jest podana w linii opisującej aktualne parametry konta użytkownika w pliku /etc/passwd.
Jeśli przekażesz polecenie wraz z opcją -s (na przykład uruchamiając sudo -s whoami), zostanie wykonane następujące polecenie: sudo /bin/bash -c whoami .
Jeśli nie spróbujesz wykonać żadnego polecenia (to znaczy po prostu uruchomisz sudo -s), będziesz mieć dostęp do interaktywnej powłoki poleceń z uprawnieniami roota.

Zauważ, że opcja -s daje ci powłokę poleceń z uprawnieniami roota, ale bez środowiska root - ta powłoka użyje twojego pliku .bashrc. Zasadniczo oznacza to, że na przykład po uruchomieniu polecenia whoami przy użyciu tej powłoki zostanie wydrukowana Twoja nazwa użytkownika, a nie root.

Opcja -tj

Opcja -i jest podobna do opcji -s, którą właśnie omówiliśmy. Istnieją jednak między nimi pewne różnice. Jedną z kluczowych różnic jest to, że opcja -i udostępnia również środowisko użytkownika root, więc plik .bashrc (użytkownika) jest ignorowany. Można to porównać do korzystania z konta użytkownika root bez logowania się jako root. Ponadto nie będziesz musiał wpisywać hasła roota.

Ważna uwaga: Pamiętaj, że istnieje również polecenie su, które pozwala na uruchamianie jako inni użytkownicy (domyślnie jesteś rootem). To polecenie wymaga hasła użytkownika root. Aby uniknąć konieczności wprowadzania hasła tego użytkownika, możesz także użyć przedrostka sudo (czyli polecenia sudo su); w tym przypadku konieczne będzie wprowadzenie hasła. Jednakże polecenia su i sudo su mają pewne różnice; aby je zrozumieć, a także zapoznać się z porównaniem tych poleceń z poleceniem sudo -i wystarczy zapoznać się z dyskusją dostępną pod tym linkiem.

Wniosek

Mam nadzieję, że przynajmniej w podstawowym stopniu wiesz, jak działa polecenie sudo i jak zmienić jego domyślne zachowanie. Wypróbuj samodzielnie modyfikacje pliku /etc/sudoers i zapoznaj się z dyskusją (do której link znajduje się w poprzednim akapicie), jeśli chcesz dowiedzieć się więcej o tym poleceniu.

Od czasów starożytnych wielu było zdezorientowanych różnorodnością opcji bezpieczeństwa podczas wykonywania operacji z maksymalnymi uprawnieniami. Na przykład w oficjalnej dokumentacji Ubuntu zaleca się użycie czegoś takiego jak Sudo nano jako polecenia do edycji, a w licznych podręcznikach amatorskich (w stylu „5 sztuczek z wierszem poleceń, które zaskoczą twoją babcię”), aby uzyskać powłokę root sugeruje się napisać sudo su - spróbuję wyjaśnić, dlaczego taki stan rzeczy wydaje mi się niewłaściwy.

Historycznie rzecz biorąc, jedynym uniwersalnym sposobem wykonania polecenia jako inny użytkownik systemu Unix był program su. Uruchamiany bez parametrów, prosił o hasło superużytkownika i, jeśli się powiedzie, po prostu zastąpił bieżącą nazwę użytkownika rootem, pozostawiając prawie wszystkie zmienne środowiskowe starego użytkownika (z wyjątkiem PATH, USER i kilku innych, zobacz man su z twojej dystrybucji ). Bardziej poprawne byłoby uruchomienie go jako su - w takim przypadku powłoka również otrzymałaby odpowiednie środowisko. Z opcją -c możesz uruchomić polecenie: su -c "vim /etc/fstab" .

W tym przypadku zaufani użytkownicy musieli pamiętać hasło roota, a wszyscy użytkownicy wymienieni w grupie „koło” (czyli w grupie, której członkowie mogli uruchomić komendę su i zostać superużytkownikiem) mieli taki sam nieograniczony dostęp do całego systemu, co stanowiło poważny problem bezpieczeństwa.

Potem pojawiła się komenda Sudo i był to przełom. Teraz administrator może określić listę dozwolonych poleceń dla każdego użytkownika (lub grupy użytkowników), pliki dostępne do edycji, specjalne zmienne środowiskowe i wiele więcej (całe to piękno jest kontrolowane z /etc/sudoers, zobacz man sudoers z twojej dystrybucji) . Po uruchomieniu sudo pyta użytkownika o jego własne hasło, a nie hasło roota. Pełną powłokę można uzyskać za pomocą „sudo -i”

Na szczególną uwagę zasługuje specjalne polecenie sudoedit, które bezpiecznie uruchamia edytor określony w zmiennej środowiskowej $EDITOR. W bardziej tradycyjnym schemacie edycja plików przebiegała w następujący sposób:
sudo vi /etc/fstab

Uruchomiony w ten sposób vi odziedziczył powłokę z nieograniczonymi prawami i poprzez:! użytkownik mógł uruchomić dowolne polecenie (o ile oczywiście administrator nie zadbał o to wcześniej) i otworzyć dowolny plik.

Sudoedit sprawdza, czy ten użytkownik może modyfikować dany plik, następnie kopiuje wskazany plik do katalogu tymczasowego, otwiera go w edytorze (który dziedziczy prawa użytkownika, a nie root), a po edycji, czy plik został zmodyfikowany, kopiuje go z zachowaniem szczególnych środków ostrożności.

W dystrybucjach opartych na Debianie użytkownik root nie ma hasła; zamiast tego wszystkie czynności administracyjne muszą być wykonywane poprzez sudo lub jego graficzny odpowiednik gksudo. Będąc całkowitym zamiennikiem su, Sudo powinno być jedyną komendą do przełączania między użytkownikami, jednak, jak powiedziano na początku, w tej chwili tak nie jest i z jakiegoś powodu wszyscy wymyślają dzikie sekwencje Sudo, su, vi i kreski.

Dlatego sugeruję każdemu, aby raz na zawsze zapamiętał:

Po pierwszej publikacji tej notatki zadano mi kilka pytań. Z odpowiedzi udało nam się stworzyć mini-FAQ.

P: Jak mogę użyć sudo do wykonania su -c "echo 1 > /etc/privileged_file"? sudo echo 1 /etc/privileged_file narzeka na „odmowę uprawnień”
O: Dzieje się tak, ponieważ wykonywane jest tylko polecenie echo z podwyższonymi uprawnieniami, a wynik jest przekierowywany do pliku z uprawnieniami zwykłego użytkownika. Aby dodać coś do pliku_uprzywilejowanego, musisz uruchomić następującą komendę:
$ echo 1| sudo tee - plik_uprzywilejowany >/dev/null
Lub tymczasowo zostań rootem:
$ sudo -i # echo 1 > plik_uprzywilejowany # wyjście $
P: Sudo -i jest dłuższe niż su - , ale wydaje się, że nie ma między nimi różnicy, po co drukować więcej?
O: Sudo ma kilka zalet, dla których warto wpisać kilka dodatkowych znaków:

domyślnie sudo rejestruje całą aktywność użytkownika w kanale authpriv syslog (z reguły wynik umieszczany jest w pliku /var/log/auth.log), a w su podobną funkcję należy włączyć ustawiając specjalny parametr w plik ustawień, który różni się w zależności od dystrybucji (SULOG_FILE w /etc/login.defs w systemie Ubuntu Linux, /etc/login.conf i /etc/pam.d/su w systemie FreeBSD itp.)
w przypadku su administrator systemu nie może ograniczać poleceń wykonywanych przez użytkowników, ale w sudo - może
jeśli użytkownik powinien zostać pozbawiony praw administracyjnych, w przypadku su po usunięciu go z grupy kołowej musi zapomnieć hasło roota; w przypadku użycia sudo wystarczy usunąć go z odpowiedniej grupy (np. Wheel lub admin) i/lub plik sudoers, jeśli został on dodatkowo dostosowany.

P: Jestem jedynym użytkownikiem w moim systemie i przywykłem do su, dlaczego potrzebuję sudo?
Odp.: Odpowiem na pytanie pytaniem: jeśli sudo jest poprawne, po co używać przestarzałego su?

Każdy właściciel serwera wie, że nie należy ufać każdemu pełnemu dostępowi (rootowi).
Znamy konsekwencje niektórych z tych momentów. A żeby ułatwić życie, Jądro Uniksa zespół wdrożył sudo.
Narzędzie, które daje użytkownikom uprawnienia do wykonywania poleceń z uprawnieniami superużytkownika. Umożliwia na przykład młodszym administratorom korzystanie z określonych poleceń w celu wykonywania zadań w ramach ich kompetencji.

Korzeń superużytkownika- konto administratora w systemie Unix (a także systemie operacyjnym uniksowym) o identyfikatorze 0, które może wykonywać wszystkie polecenia bez wyjątku.

Zainstalowany z repozytoriów przy użyciu menedżera pakietów: apt-get zainstaluj sudo Lub mniam, zainstaluj Sudo.

konfiguracja sudo pozwala określić użytkownika, grupę użytkowników, hosty oraz to, czy do wykonania wymagane jest hasło.
Na przykład wykonanie polecenia w imieniu innego użytkownika.

Uruchom Midnight Commandera jako superużytkownik

Otwórz w edytorze tekstu nano plik nginx.config od użytkownika Anton.

Sudo -u anton nano /etc/nginx/nginx.config

Plik konfiguracyjny sudoerzy znajdujący się w katalogu /itp/.
Aby edytować plik konfiguracyjny, użyj polecenia wizualizacja.

Nie powinieneś zmieniać pliku /etc/sudoers za pomocą edytora tekstu, ponieważ... Podczas zapisywania składnia nie jest sprawdzana, jak ma to miejsce w przypadku wizualizacja.

Szablon praw użytkownika w pliku konfiguracyjnym /etc/sudoers

Użytkownik/%grupa ALL/nazwa_hosta/+grupa_komputera = ALL/polecenia_oddzielone przecinkami (dodatkowe parametry):

Umożliwia użytkownikowi Antonowi uruchamianie wszystkich poleceń na wszystkich hostach (z pytaniem o hasło)

Anton WSZYSTKIE=(WSZYSTKIE) WSZYSTKIE

Umożliwia grupie administratorów uruchamianie wszystkich poleceń na komputerze Alpha (bez wprowadzania hasła)

%admins Alpha = WSZYSTKIE NOPASSWD: WSZYSTKIE

Domyślnie podczas wykonywania poleceń za pośrednictwem sudo wymagane jest zalogowanie się przy użyciu hasła. Możesz wyłączyć autoryzację za pomocą parametru NIEPASSWD)

Dostarczane przez sudo i grupowanie poleceń w aliasy.
Łączenie poleceń do pracy z siecią w jedną całość SIEĆ

Cmnd_Alias NETWORKING = /sbin/route, /sbin/ifconfig, /bin/ping, /sbin/dhclient, /usr/bin/net, /sbin/iptables, /usr/bin/rfcomm, /usr/bin/wvdial , /sbin/iwconfig, /sbin/mii-tool

Można je wykorzystać np ograniczenie praw użytkownikowi lub grupie do wykonywania poleceń mających wpływ na usługę.

Zezwalaj na używanie wszystkich poleceń przez użytkownika Egor i grupę devops, z wyjątkiem tych z grupy NETWORKING

Egor ALL = WSZYSTKIE, !NETWORKING %devops ALL = WSZYSTKIE, !NETWORKING

Przyjrzeliśmy się niektórym funkcjom sudo; aby uzyskać szczegółowe informacje, użyj strony podręcznika z Twojej dystrybucji.

Dlatego sugeruję każdemu, aby raz na zawsze zapamiętał:

Po pierwszej publikacji tej notatki zadano mi kilka pytań. Z odpowiedzi udało nam się stworzyć mini-FAQ.

domyślnie sudo rejestruje całą aktywność użytkownika w kanale authpriv syslog (z reguły wynik umieszczany jest w pliku /var/log/auth.log), a w su podobną funkcję należy włączyć ustawiając specjalny parametr w plik ustawień, który różni się w zależności od dystrybucji (SULOG_FILE w /etc/login.defs w systemie Ubuntu Linux, /etc/login.conf i /etc/pam.d/su w systemie FreeBSD itp.)
w przypadku su administrator systemu nie może ograniczać poleceń wykonywanych przez użytkowników, ale w sudo - może
jeśli użytkownik powinien zostać pozbawiony praw administracyjnych, w przypadku su po usunięciu go z grupy kołowej musi zapomnieć hasło roota; w przypadku użycia sudo wystarczy usunąć go z odpowiedniej grupy (np. Wheel lub admin) i/lub plik sudoers, jeśli został on dodatkowo dostosowany.

P: Jestem jedynym użytkownikiem w moim systemie i przywykłem do su, dlaczego potrzebuję sudo?
Odp.: Odpowiem na pytanie pytaniem: jeśli sudo jest poprawne, po co używać przestarzałego su?

Sudo to program do Podobny do Uniksa systemy operacyjne, które umożliwiają użytkownikom uruchamianie programów z uprawnieniami innego użytkownika, domyślnie superużytkownika.

W przeciwieństwie do połączonego polecenia su, użytkownicy muszą podać swoje hasło w celu uwierzytelnienia. Po uwierzytelnieniu, jeśli plik konfiguracyjny, który zwykle znajduje się w /etc/sudoers, umożliwia nadanie użytkownikowi dostępu, system wykonuje żądane polecenie. Plik konfiguracyjny daje uprawnienia dostępu, w tym umożliwia wykonywanie poleceń wywoływanych z terminala; pozwala żądać hasło dla każdego użytkownika lub grupy; pozwala na żądanie ponownego wprowadzenia hasła za każdym razem lub w ogóle nie wymaganie wprowadzania hasła. Można go również skonfigurować tak, aby zezwalał na przekazywanie argumentów lub wielu poleceń.

Krótko mówiąc, aby wykonać określone czynności w Linuksa, będziemy musieli wprowadzić hasło lub zalogować się jako superużytkownik (nie).
Spójrzmy na prosty przykład, aby móc usunąć\kopiować\zamienić pliki systemowe Ubuntu, musisz otworzyć menedżera plików Łodzik w imieniu superużytkownika.
Aby to zrobić, wpisz w terminalu ( ctrl+alt+T). Uważaj, w terminalu rozróżniana jest wielkość liter.

sudo nautilus

Pojawi się wówczas następujący tekst:

hasło dla użytkownika: /wpisz tutaj swoje hasło, pamiętaj, że żadne znaki nie będą wyświetlane/

W ten sposób otworzyłeś menedżera plików Łodzik w imieniu superużytkownika i teraz możesz bezpiecznie (lub nie tak bardzo) majstrować przy plikach systemowych ^^

Następny przykład. Na przykład musisz majstrować przy zawartości pliku systemowego za pomocą edytora tekstu, ale nie możesz wprowadzać w nim zmian. Otwórz terminal i wpisz:

sudo gedit

W ten sposób otworzyłeś edytor tekstu z uprawnieniami administratora.

Inny przykład: załóżmy, że uruchamiasz dużą liczbę poleceń i za każdym razem wpisywanie hasła po prostu Ci nie odpowiada. Możesz otworzyć sesję superużytkownika w terminalu, co uratuje Cię od tych niedogodności.
Wpisz w terminalu:

sudo su

Następnie wprowadź hasło, sesja superużytkownika jest otwarta. Dziękuję za uwagę