☰

Warum funktioniert „requiretty“ nicht?

tag-icon • tag-icon debian ssh sudo
Warum funktioniert „requiretty“ nicht?

Meines Wissens requirettylässt die Option kein Sudo auf PTYs zu.

Meine 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`

Nach der Verbindung mit diesem System über SSH gibt das ttyProgramm aus /dev/pts/0.

Aber ich kann in der SSH-Sitzung immer noch mit einem Passwort sudo verwenden. Hat diese requirettyOption nichts mit SSH oder PTYs zu tun? Wie kann ich in meiner SSH-Sitzung sudo verwenden?

Antwort1

Ihr Verständnis ist nicht richtig: Ein Pseudo-TTY wird als völlig gleichwertig zu einem „echten“ TTY angesehen.

Wenn ttyes gedruckt wird, /dev/pts/0bedeutet dies, dass die Sitzung über ein gültiges TTY verfügt.

Wenn Sie jedoch mit den SSH-Standardeinstellungen eine Verbindung zur VM herstellen und den auszuführenden Befehl angeben, ist die Situation anders:

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

UndDasist die Situation, die durch sudodie requirettyOption von abgelehnt wurde.

Durch die Anforderung eines TTY kann SSH Versuche ablehnen, die Antwort auf die Kennwortabfrage über die Standardeingabe weiterzuleiten, wie dies viele andere Unix-Programme bei der Anforderung eines Kennworts tun.

Sie können damit auch folgende Dinge tun:

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

ohne dass die Kennwortabfrage weder in die an weitergeleiteten Daten data_consuming_commandnoch in die eingemischt wird error-log-file. (Beachten Sie, dass data_consuming_commandSie es hier als Sie selbst ausführen, nicht als some-user!)

Mit anderen Worten: Mit requiretty„set“ können Sie Folgendes nicht sudoin Kontexten wie diesen verwenden:

  • Remote-Befehle über SSH, es sei denn, Sie erzwingen die TTY-Zuweisung. Dies ssh VM-user@VM-host sudo somethingwürde fehlschlagen, aber ssh -tt VM-user@VM-host sudo somethingerfolgreich sein.
  • crontab-Befehle oder Skripte, die über crontab- oder atoder batch-Befehle ausgeführt werden
  • Skripte, die ausgeführt werden übernohup
  • Skripte, die über cgi-binoder einen anderen Daemon-Prozess ausgeführt werden, der keine Beziehung zu Benutzersitzungen hat

Wenn requirettyfestgelegt ist und sudoein Kennwort anfordert, geschieht dies auf eine Weise, die vom Konzept her ungefähr diesem Skriptausschnitt ähnelt:

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/ttyist ein „magisches“ Gerät, das immer als Alias ​​des tatsächlichen TTY-Geräts der Sitzung fungiert, wenn die Sitzung über ein TTY verfügt. Es existiert genau für solche Dinge: um jedem Skript oder Programm zu ermöglichen, Pipes oder andere Eingabe-/Ausgabeumleitungen zu „entkommen“ und bei Bedarf direkt mit dem Benutzer zu interagieren.

Wenn requirettyfestgelegt und /dev/ttynicht verwendbar ist (d. h. wenn dem Prozess kein echtes TTY zugeordnet ist), wird es wie ein Fehler bei der Kennwortauthentifizierung behandelt.

verwandte Informationen