sudo z hasłem w jednym wierszu poleceń?

Tak, użyj przełącznika -S, który odczytuje hasło z STDIN:

$echo <password> | sudo -S <command>

Tak więc w Twoim przypadku wyglądałoby to tak:

$./configure && make && echo <password> | sudo -S make install && halt

oczywiście zastąp <password> swoim hasłem.

Można również skonfigurować sudo z visudo, aby umożliwić użytkownikowi użycie make as sudo bez hasła.

User_Alias USERS = your_user
Cmnd_Alias CMDS = /usr/bin/make
USERS ALL = (ALL) NOPASSWD: CMDS

Kilka innych rozwiązań ma tę wadę, że niepotrzebnie uruchamiają ./configure i make jako root.

Jest to trochę zagmatwane, ale powinno działać:

sudo sh -c "su $USER -c ./configure && su $USER -c make && make install && halt"

Zwróć uwagę na użycie cudzysłowów, aby umożliwić rozszerzenie $USER o (nie-korzenną) powłokę.

Mogę też dodać sleep 60 przed komendą halt. Czasami robię takie rzeczy, oczekując, że komenda będzie działać przez długi czas, ale coś idzie nie tak i natychmiast się kończy; sleep pozwala mi zabić komendę zanim system się wyłączy. Albo możesz użyć shutdown z argumentem czasu.

Możesz zastąpić swój wiersz poleceń tym:

$sudo su

$./configure && make && make install && halt

Zostaniesz natychmiast poproszony o podanie hasła, a następnie reszta poleceń będzie działać jako superuser.

Ustaw HISTIGNORE na “sudo -S”

$ export HISTIGNORE='*sudo -S*'

Następnie przekaż bezpiecznie hasło do sudo:

$ echo "your_password" | sudo -S -k <command>

“HISTIGNORE” oznacza nie zapisywanie tego polecenia w historii. Jest to historia w pamięci lub plik “~/.bash_history”.

Na przykład, poniżej, bezpiecznie przeniesie Twoje hasło do polecenia sudo, bez zachowania historii Twojego hasła.

“-S”, oznacza użycie stdin dla hasła,

“-k” oznacza zignorowanie zbuforowanych danych uwierzytelniających, aby zmusić sudo do ciągłego pytania. To jest dla spójnego zachowania.

$ export HISTIGNORE='*sudo -S*'
$ echo "<your_password>" | sudo -S -k whoami
$ echo "<your_password>" | sudo -S -k cat /etc/shadow
$ echo "<your_password>" | sudo -S -k bash /tmp/myscript.sh

Wadą powyższej metody jest to, że jeśli chcesz zobaczyć komendy, które wykonałeś w historii później, nie będzie ich tam. Inną metodą jest aktualizacja pamięci podręcznej uwierzytelniania sudo (domyślnie jest włączona z 5 minutowym timeoutem), a następnie uruchomienie sudo oddzielnie. Ale minusem tego jest to, że musisz być świadomy 5-minutowego cache'u.

Na przykład:

$ export HISTIGNORE='*sudo -S*'
$ echo "<your_password>" | sudo -S -v
$ sudo whoami
$ echo "<your_password>" | sudo -S -v
$ sudo cat /etc/shadow
$ echo "<your_password>" | sudo -S -v
$ sudo /tmp/myscript.sh

Uwaga Uruchomiłem sudo przed każdym poleceniem, aby upewnić się, że cache sudo jest aktualizowany, ponieważ domyślnie jest to 5 minut. Tak, whoami nie powinno zająć 5 minut, ale myślę, że równie dobrze może uruchomić go przed każdym poleceniem dla spójności. Możesz również umieścić “export HISTIGNORE=‘sudo -S’” w swoim pliku ~/.bashrc, a następnie załadować go za pomocą “. ~/.bashrc” lub logoff, a następnie zaloguj się. Jednakże, myślę o użyciu tego do celów skryptowych, więc będę trzymał to na szczycie wszystkich moich skryptów dla najlepszych praktyk bezpieczeństwa. Ustawienie “echo ” | sudo -S -v" na zmienną zamiast tego może być również dobrym pomysłem, a następnie po prostu uruchom zmienną przed każdym poleceniem, które potrzebuje uprawnień roota, zobacz komentarz Janara. Komentarz “John T” powinien również zawierać parametr “-k”, tak jakbyś uruchomił “sudo -S” bez “-k”, a cache uwierzytelniający sudo miał już Twoje dane uwierzytelniające (i jest nadal ważny, domyślny cache uwierzytelniający sudo wynosi 5 minut), wtedy bash uruchomi Twoje hasło jako polecenie, co jest złe.

Ty też możesz to zrobić:

sudo -S <<< "password" command

Zauważ, że metoda ta nie działa na starszej wersji sudo, a konkretnie na “Sudo version 1.6.7p5”:

$ echo "<your_password>" | sudo -S -k whoami

Gdzie jak ta metoda działa na starszych i nowych wersjach sudo:

$ echo "<your_password>" | sudo -S -v
$ sudo whoami

Jeśli chcesz zachować większą ostrożność, możesz zrobić skrypt, zmienić uprawnienia do pliku, tak aby tylko root mógł go odczytać i edytować, a następnie po prostu uruchomić.

Przykład: 1) Utwórz plik:

gedit ~/.easy.install

2) Wklej to i zapisz:

./configure && make && echo <password> | sudo -S make install && halt

3) Wykonaj to:

sudo chmod +x ~/.easy.install

4) Zmień uprawnienia pliku tak, aby tylko root mógł go odczytać i edytować:

sudo chmod 700 ~/.easy.install

5) Uruchom:

~/.easy.install

Enjoy ;-)

Ustawienie takiego sudo jest niebezpieczne, jeśli ktoś zauważy, że sudo nie wymaga hasła na Twoim koncie. Jeśli nie wiesz, co robisz, nie rób tego. Miałem to w moim lokalnym programie szkoleniowym A+ z moim eksperymentalnym komputerem o jeden raz za dużo razy… -{\i1}-

To, co powiedział John T., brzmi nieźle, chyba że nadal istnieje ryzyko znalezienia hasła w historii powłoki. To co powiedział CarlF brzmi lepiej, ale jeśli jedna komenda zawiedzie, komputer nadal będzie działał z uprawnieniami superużytkownika.

Problem jest rozwiązany. Na przykład, do użytkownika root:

echo -e 'password\npassword\n' | sudo passwd root

Osobiście robię to samo, co John T odpowiedział 9 listopada 2009 roku o 2:47, poprawiłem też swoje według wskazówek jego odpowiedzi, dzięki.

Różnica polega na tym, że mam tendencję do używania zmiennych, coś w rodzaju:

AutoSuDo=$" $echo pass | sudo -S";
# Change AutoSuDo to something else.
# Note that string starts with space,
# useful only if used as first command in line

W ten sposób mogę łatwo używać moich zmiennych zamiast sudo,

$AutoSuDo apt-get update;

To się przydaje w przypadku kilku dłuższych skryptów. Skrypty te wykorzystuję głównie na komputery osobiste innych osób, które muszę utrzymywać.

Polecam również zwrócić uwagę na:

• desgua answer on Apr 19 ‘11 at 23:56
• user224306 comment on May 14 '13 at 17:38 for John T answer on Nov 9 '09 at 2:47.