В напряженные дни я хотел бы бежать
$ ./configure && make && sudo make install && halt
на ночь и ложитесь спать, надеясь, что приложение будет установлено автоматически. Но на следующий день я вижу экран, на котором sudo спрашивает у меня пароль. Итак, как я могу запустить sudo с паролем в одной командной строке, или есть другой способ сделать это?
Да, используйте ключ -S который считывает пароль из STDIN:
$echo <password> | sudo -S <command>
Так что для вашего случая это будет выглядеть так:
$./configure && make && echo <password> | sudo -S make install && halt
конечно, замените <password> своим паролем.
Вы также можете настроить sudo с помощью visudo чтобы пользователь мог использовать make как sudo без пароля.
User_Alias USERS = your_user
Cmnd_Alias CMDS = /usr/bin/make
USERS ALL = (ALL) NOPASSWD: CMDS
Недостатком некоторых других решений является то, что они излишне запускаются ./configure и make как root.
Это немного запутанно, но это должно работать:
sudo sh -c "su $USER -c ./configure && su $USER -c make && make install && halt"
Обратите внимание на использование двойных кавычек, чтобы разрешить расширение $USER оболочкой (без полномочий root).
Я мог бы также добавить sleep 60 перед командой halt . Иногда я делал такие вещи, ожидая, что команда будет выполняться в течение длительного времени, но что-то идет не так, и это немедленно прекращается; sleep позволяет мне убить команду, прежде чем система выключится. Или вы можете использовать shutdown с аргументом времени.
Вы можете заменить вашу командную строку следующим образом:
$sudo su
$./configure && make && make install && halt
Вам будет предложено ввести пароль немедленно, затем остальные команды будут запущены с правами суперпользователя.
Установите HISTIGNORE на " sudo -S "
$ export HISTIGNORE='*sudo -S*'
Затем безопасно передайте свой пароль sudo:
$ echo "your_password" | sudo -S -k <command>
"HISTIGNORE" означает не сохранять эту команду в историю. Это история в памяти или файл "~/.bash_history".
Например, ниже приведен безопасный путь вашего пароля к команде sudo, без сохранения истории вашего пароля.
«-S» означает использовать стандартный пароль для пароля,
«-K» означает игнорировать кэшированные учетные данные, чтобы заставить sudo всегда спрашивать. Это для последовательного поведения.
$ 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
Недостатком вышеописанного метода является то, что если вы хотите увидеть команды, которые вы запускали в истории, их больше не будет. Другой способ заключается в обновлении кэша учетных данных аутентификации sudo (по умолчанию включено с 5-минутным таймаутом), затем запустите sudo отдельно. Но недостатком этого является то, что вам нужно знать о 5-минутном кеше.
Например:
$ 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
Примечание. Я запускал sudo перед каждой командой, чтобы убедиться, что кэш sudo обновляется, поскольку по умолчанию установлено значение 5 минут. Да, whoami не должно занимать 5 минут, но я полагаю, что он может запускаться перед каждой командой для обеспечения согласованности. Вы также можете поместить "export HISTIGNORE = ' sudo -S '" в файл ~/.bashrc, а затем загрузить его с помощью ". ~/.bashrc "или выйдите из системы, затем войдите. Тем не менее, я думаю использовать это в целях написания сценариев, поэтому я буду держать его на вершине всех моих сценариев для лучшей практики безопасности. Вместо этого также может быть полезно установить "echo" "| sudo -S -v" в переменную, а затем просто запускать переменную перед каждой командой, которой нужны привилегии root, см. Комментарий Janar. Комментарий "John T" также должен включать параметр «-k», как будто вы запускаете «sudo -S» без «-k», а кеш аутентификации sudo уже имеет ваши учетные данные (и все еще действителен, кеш аутентификации sudo по умолчанию равен 5 минут), тогда bash запустит ваш пароль вместо команды, что плохо.
Ты тоже можешь это сделать:
sudo -S <<< "password" command
Если вы хотите быть более внимательным, вы можете создать скрипт, изменить права доступа к файлу, чтобы только root мог читать и редактировать, а затем просто запустить его.
Пример:
1) Создайте файл:
gedit ~/.easy.install
2) Вставьте это и сохраните:
./configure && make && echo <password> | sudo -S make install && halt
3) Сделайте его исполняемым:
sudo chmod +x ~/.easy.install
4) Измените права доступа к файлу, чтобы только root мог читать и редактировать его:
sudo chmod 700 ~/.easy.install
5) Выполнить:
~/.easy.install
Наслаждаться ;-)
Подобная настройка sudo опасна, если кто-то случайно увидел, что sudo не требует пароля в вашей учетной записи. Если вы не знаете, что делаете, не делайте этого. У меня это случалось в моей местной программе обучения А + с моим экспериментальным компьютером слишком много раз ... -_-
То, что сказал Джон Т., звучит неплохо, но есть риск найти пароль в истории оболочки. То, что сказал CarlF, звучит лучше, но если одна из команд не будет выполнена, компьютер все равно будет работать с привилегиями суперпользователя.
Обратите внимание, я обнаружил, что этот метод не работает в более старой версии sudo, а именно в «Sudo version 1.6.7p5»:
$ echo "<your_password>" | sudo -S -k whoami
Где, как этот метод работает на старых и новых версиях sudo:
$ echo "<your_password>" | sudo -S -v
$ sudo whoami
Проблема устранена. Например, для пользователя root:
echo -e 'password\npassword\n' | sudo passwd root
Лично я делаю то же самое, что Джон Т ответил 9 ноября 2009 года в 2:47, я также улучшил свой согласно руководству его ответа, спасибо.
Разница в том, что я склонен использовать переменные, что-то вроде:
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
Таким образом, я могу легко использовать мою переменную вместо sudo,
$AutoSuDo apt-get update;
Это очень удобно с некоторыми более длинными сценариями. Я в основном использую их для персональных компьютеров других, которые я должен поддерживать.
Также рекомендую обратить внимание на: