Ssh – Benötigen Sie ein Tty, um Sudo auszuführen, wenn ich Sudo ohne Passwort ausführen kann?

Ich habe sudo konfiguriert ohne Passwort auszuführen, aber wenn ich versuche, ssh 'sudo Foo' zu senden , erhalte ich immer noch die Fehlermeldung sudo: sorry, you must have a tty to run sudo .

Warum passiert das und wie kann ich es umgehen?

Akzeptierte Antwort:

Das liegt wahrscheinlich daran, dass Ihre /etc/sudoers Datei (oder jede darin enthaltene Datei) hat:

Defaults requiretty

… was sudo ergibt erfordern ein TTY. Es ist bekannt, dass Red Hat-Systeme (RHEL, Fedora…) ein TTY in standardmäßigen sudoers erfordern Datei. Das bietet keinen wirklichen Sicherheitsvorteil und kann sicher entfernt werden.

Red Hat hat das Problem erkannt und es wird in zukünftigen Versionen entfernt.

Wenn das Ändern der Konfiguration des Servers keine Option ist, können Sie als Workaround für diese Fehlkonfiguration den -t verwenden oder -tt Optionen zu ssh das ein Pseudo-Terminal auf der entfernten Seite erzeugt, aber beachten Sie, dass es eine Reihe von Nebeneffekten hat.

-tt ist für die interaktive Nutzung gedacht. Es versetzt das lokale Terminal in raw Modus, damit Sie mit dem entfernten Terminal interagieren können. Das heißt, wenn ssh I/O ist nicht von/zu einem Terminal, das hat Nebeneffekte. Beispielsweise werden alle Eingaben zurückgesendet, spezielle Terminalzeichen (^? , ^C , ^U ) führt zu einer besonderen Verarbeitung; bei Ausgabe LF s werden in CRLF umgewandelt s… (siehe diese Antwort auf Warum wird diese Binärdatei geändert? für weitere Details.

Um die Auswirkungen zu minimieren, könnten Sie es wie folgt aufrufen:

ssh -tt host 'stty raw -echo; sudo ...' < <(cat)

Der < <(cat) vermeidet die Einstellung des lokalen Terminals (falls vorhanden) in raw Modus. Und wir verwenden stty raw -echo um die Leitungsdisziplin des entfernten Terminals auf Pass-Through zu setzen (effektiv, damit es sich wie die Pipe verhält, die anstelle eines Pseudo-Terminals ohne -tt verwendet würde , obwohl dies nur gilt, nachdem dieser Befehl ausgeführt wurde, also müssen Sie das Senden von Eingaben verzögern, bis dies geschieht).

Beachten Sie, dass, da die Ausgabe des Remote-Befehls an ein Terminal geht, dies immer noch die Pufferung (die für viele Anwendungen zeilenbasiert sein wird) und die Bandbreiteneffizienz seit TCP_NODELAY beeinflusst ist an. Auch mit -tt , ssh setzt IPQoS auf lowdelay im Gegensatz zu throughput . Sie könnten beides umgehen mit:

ssh -o IPQoS=throughput -tt host 'stty raw -echo; sudo cmd | cat' < <(cat)

Beachten Sie auch, dass dies bedeutet, dass der Remote-Befehl das Dateiende auf seiner stdin nicht erkennen kann und dass stdout und stderr des Remote-Befehls zu einem einzigen Stream zusammengeführt werden.

Siehe auch:Debian – Benutzer und Passwort bei der Anmeldung in Debian 9 Stretch entfernen?

Also doch keine so gute Umgehung.

Wenn Sie eine Möglichkeit haben, ein Pseudo-Terminal auf dem Remote-Host zu spawnen (wie mit expect , zsh , socat , perl ‘s IO::Pty …), dann wäre es besser, damit das Pseudo-Terminal zu erstellen, um sudo anzuhängen zu (aber nicht für I/O) und verwenden Sie ssh ohne -t .

Zum Beispiel mit expect :

ssh host 'expect -c "spawn -noecho sh -c {
     exec sudo cmd >&4 2>&5 <&6 4>&- 5>&- 6<&-}
 exit [lindex [wait] 3]" 4>&1 5>&2 6<&0'

Oder mit script (hier unter der Annahme der Implementierung von util-linux ):

ssh host 'SHELL=/bin/sh script -qec "
              sudo cmd <&3 >&4 2>&5 3<&- 4>&- 5>&-
            " /dev/null 3<&0 4>&1 5>&2'

(unter der Annahme (für beide), dass die Login-Shell des entfernten Benutzers Bourne-ähnlich ist).