☰

¿Por qué no funciona "requiretty"?

tag-icon • tag-icon debian ssh sudo
¿Por qué no funciona "requiretty"?

Tengo entendido que la requirettyopción no permite sudo en PTY.

Mis máquinas virtuales 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`

Después de conectarse a este sistema con SSH, el ttyprograma genera /dev/pts/0.

Pero todavía puedo sudo con una contraseña en la sesión SSH. ¿Esta requirettyopción no tiene nada que ver con SSH o PTY? ¿Cómo puedo sudo en mi sesión SSH?

Respuesta1

Su comprensión no es correcta: un pseudo-TTY se considera totalmente equivalente a un TTY "real".

Cuando ttyse imprime /dev/pts/0significa que la sesión tiene un TTY válido.

Pero si se conecta a la VM con la configuración predeterminada de SSH y especifica el comando a ejecutar, la situación será diferente:

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

yesoes la situación rechazada por la opción sudode requiretty.

El requisito de un TTY permite que SSH rechace los intentos de canalizar la respuesta a la solicitud de contraseña a través de una entrada estándar, como lo hacen muchos otros programas Unix cuando solicitan una contraseña.

También te permite hacer cosas como esta:

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

sin que la solicitud de contraseña se mezcle con los datos canalizados data_consuming_commanda error-log-file. (¡Tenga en cuenta que data_consuming_commandaquí se ejecuta como usted mismo, no como some-user!)

En otras palabras, con requirettyset, no puedes usarlo sudoen contextos como:

  • comandos remotos a través de SSH a menos que fuerce la asignación de TTY, es decir, ssh VM-user@VM-host sudo somethingfallaría, pero ssh -tt VM-user@VM-host sudo somethingtendría éxito.
  • Comandos crontab o scripts ejecutados mediante comandos crontab o atorbatch
  • guiones ejecutados mediantenohup
  • scripts ejecutados a través de cgi-bincualquier otro proceso demonizado que no tenga relación con las sesiones de usuario

Cuando requirettyestá configurado y sudosolicita una contraseña, lo hace de una manera más o menos similar en concepto a este fragmento de script:

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/ttyes un dispositivo "mágico" que siempre actuará como un alias del dispositivo TTY real de la sesión, si la sesión tiene un TTY. Existe precisamente para cosas como esta: permitir que cualquier script o programa "escapare" de la tubería u otra redirección de entrada/salida e interactúe directamente con el usuario cuando sea necesario.

Si requirettyestá configurado y /dev/ttyno se puede utilizar (es decir, cuando el proceso no tiene un TTY real asociado), se trata de la misma manera que un error de autenticación de contraseña.

información relacionada