☰

Почему «requiretty» не работает?

tag-icon • tag-icon debian ssh sudo
Почему «requiretty» не работает?

Насколько я понимаю, эта requirettyопция не позволяет использовать sudo на PTY.

Мои виртуальные машины sudoers:

#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
Defaults        passwd_tries=3
Defaults        badpass_message="WRONG PASSWORD T_T"
Defaults        log_input, log_output, iolog_dir="/var/log/sudo"
Defaults        requiretty
# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d`

После подключения к этой системе по SSH ttyпрограмма выводит /dev/pts/0.

Но я все еще могу sudo с паролем в сеансе SSH. Имеет ли эта requirettyопция какое-либо отношение к SSH или PTY? Как я могу sudo в моем сеансе SSH?

решение1

Вы понимаете неправильно: псевдо-TTY считается полностью эквивалентным «настоящему» TTY.

Если ttyпечатается, /dev/pts/0это означает, что сеанс имеет действительный TTY.

Но если подключиться к виртуальной машине с настройками SSH по умолчанию и указать команду для запуска, ситуация будет иной:

$ ssh VM-user@VM-hostname "hostname; tty"
VM-hostname
not a tty

ичтоситуация, отвергнутая sudoвариантом requiretty.

Требование наличия TTY позволяет SSH отклонять попытки передать ответ на запрос пароля через стандартный ввод, как это делают многие другие программы Unix при запросе пароля.

Он также позволяет вам делать такие вещи:

sudo -u some-user data_producing_command 2> error-log-file | data_consuming_command

без подсказки пароля, которая не будет смешана ни с данными, передаваемыми в data_consuming_command, ни с данными в error-log-file. (Обратите внимание, что data_consuming_commandздесь выполняется запуск от вашего имени, а не от имени some-user!)

Другими словами, с requirettyset вы не можете использовать sudoв таких контекстах, как:

  • удаленные команды через SSH, если только вы не принудительно выделите TTY, т.е. ssh VM-user@VM-host sudo somethingне будут выполнены, но ssh -tt VM-user@VM-host sudo somethingтакже будут выполнены успешно.
  • команды crontab или скрипты, выполняемые с помощью crontab atили batchкоманд
  • скрипты, выполняемые черезnohup
  • скрипты, выполняемые через cgi-binили любой другой демонизированный процесс, который не имеет отношения к сеансам пользователя

Когда requirettyустановлено и sudoзапрашивается пароль, он делает это способом, который по своей концепции примерно похож на этот фрагмент скрипта:

printf "[sudo] password for $USER: " > /dev/tty  # display prompt

TTYSETTINGS=$(stty -F /dev/tty --save)  # save current TTY settings
stty -F /dev/tty -echo -echoe           # prevent displaying the password

read PASSWORD < /dev/tty  

stty -F /dev/tty $TTYSETTINGS           # restore TTY settings 
# now check if $PASSWORD is correct...

/dev/ttyэто "волшебное" устройство, которое всегда будет действовать как псевдоним фактического устройства TTY сеанса, если сеанс имеет TTY. Оно существует именно для таких вещей: чтобы позволить любому скрипту или программе "избежать" конвейеризации или другого перенаправления ввода/вывода и напрямую взаимодействовать с пользователем, когда это необходимо.

Если requirettyустановлено и /dev/ttyне может быть использовано (т. е. когда процесс не имеет реального связанного с ним TTY), это рассматривается так же, как и сбой аутентификации пароля.

Связанный контент