☰

Por que "requiretty" não está funcionando?

tag-icon • tag-icon debian ssh sudo
Por que "requiretty" não está funcionando?

Entendo que a requirettyopção não permite sudo em PTYs.

Minhas VMs 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`

Depois de conectar-se a este sistema com SSH, o ttyprograma gera /dev/pts/0.

Mas ainda posso sudo com uma senha na sessão SSH. Esta requirettyopção não tem nada a ver com SSH ou PTYs? Como posso sudo na minha sessão SSH?

Responder1

Seu entendimento não está correto: um pseudo-TTY é considerado totalmente equivalente a um TTY "real".

Quando ttyimpresso /dev/pts/0significa que a sessão possui um TTY válido.

Mas se você se conectar à VM com configurações padrão de SSH e especificar o comando a ser executado, a situação será diferente:

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

equeé a situação rejeitada pela opção sudode requiretty.

O requisito de um TTY permite que o SSH rejeite tentativas de canalizar a resposta ao prompt de senha por meio de entrada padrão, como muitos outros programas Unix fazem ao solicitar uma senha.

Também permite que você faça coisas como esta:

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

sem que o prompt de senha não seja misturado aos dados canalizados data_consuming_commandnem ao error-log-file. (Observe que data_consuming_commandaqui é executado como você mesmo, não como some-user!)

Em outras palavras, com requirettyset, você não pode usar sudoem contextos como:

  • comandos remotos via SSH, a menos que você force a alocação de TTY, ou seja, ssh VM-user@VM-host sudo somethingfalharia, mas ssh -tt VM-user@VM-host sudo somethingteria sucesso.
  • comandos crontab ou scripts executados via crontab atou batchcomandos
  • scripts executados vianohup
  • scripts executados por meio de cgi-binou qualquer outro processo daemonizado que não tenha relação com sessões de usuário

Quando requirettyestá definido e sudosolicita uma senha, ele faz isso de uma maneira que é aproximadamente semelhante em conceito a este trecho 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/ttyé um dispositivo "mágico" que sempre atuará como um alias do dispositivo TTY real da sessão, se a sessão tiver um TTY. Ele existe precisamente para coisas como esta: permitir que qualquer script ou programa "escape" da tubulação ou outro redirecionamento de entrada/saída e interaja diretamente com o usuário quando necessário.

Se requirettyestiver definido e /dev/ttynão for utilizável (ou seja, quando o processo não tiver nenhum TTY real associado a ele), será tratado da mesma forma que uma falha de autenticação de senha.

informação relacionada