当ssh客户端的参数后面是交互式程序时,为什么sshd不使用伪终端?


11

连接到SSH服务器的正常方法是ssh username@ip_address。但是用户可能只想在远程计算机上运行程序。因此,程序名称后跟普通参数ssh username@ip_address <program_name>。例如,ssh username@ip_address ls。除了交互式程序(还接受用户输入并提供输出)之外,该参数很好top。输出是

TERM环境变量未设置。

这意味着sshd和top程序之间没有连接(伪)终端。解决方法是-t在整个命令现在变为的地方添加参数ssh -t username@ip_address top

我的问题是,为什么默认情况下sshd也不能使用伪终端与非交互式程序进行通信,因此无需-t为交互式程序添加参数?


3
简短的答案是“因为通常这不是您想要的”。
塞拉达

我预计您的问题会因本质上乞求意见/抱怨而变得温和。但是,让我们绕开一个问题:在大多数情况下,当不需要tty时,ssh为什么要分配tty资源?真正的问题是:为什么不将force-tty分配为配置选项,以便您可以将其设为默认值或特定于主机的默认值?
Otheus

@Otheus 配置选项。您可以在配置中设置RequestTTY yes(或force)。
雅库耶

的确。似乎已在6中引入,但直到不久之后才出现故障。我只使用非常旧的发行版。:)
Otheus

6
SSH如何可靠地知道程序是交互式的?甚至top可以批处理模式运行。
大师

Answers:


18

正如其他人所说,PTY确实有一定的开销-但是在运行远程命令时不使用PTY的主要原因是您丢失了信息。

通常,当您通过ssh远程运行命令时,命令stdoutstderr流将发送到本地stdoutstderr,这意味着您可以分别重定向/管道处理它们,例如:

$ ssh server ls foo bar
ls: cannot access bar: No such file or directory
foo
$ ssh server ls foo bar > stdout 2> stderr
$ cat stdout
foo
$ cat stderr
ls: cannot access bar: No such file or directory

但是,如果您使用的是PTY,则所有输出都转到stdout,因为PTY没有用于输出/错误的单独流:

$ ssh -t server ls foo bar > stdout 2> stderr
$ cat stdout
ls: cannot access bar: No such file or directory
foo
$ cat stderr
$

这是我没有意识到的一个好点。
Jakuje

1
@ThomasDickey:几乎...问题不是“开发人员选择此默认设置背后的历史原因是什么”,而是“为什么默认情况下无法使用sshd使用伪终端”(重点是我的,而是措辞或多或少直接来自于问题)。因此,行为上的差异(会破坏许多脚本习惯用法)是相关的,与开发人员如何做出选择无关:-)
psmears

2
@ThomasDickey:你甚至读过这个问题吗?它在哪里提到开发商的意见?
psmears '16

1
+1指出了使用pty 的特定优势(性能除外)。您仍然可能会认为这-t应该是默认值,并且需要关闭它的选项,因此,在无关紧要的情况下,真正的次要性能优势对我来说才最有意义。
彼得·科德斯

7

手册页ssh对此进行了描述:

服务器接受用户身份后,服务器将在非交互式会话中执行给定命令,或者,如果未指定命令,则登录到计算机并为用户提供一个普通外壳作为交互式会话。与远程命令或外壳程序的所有通信都将被自动加密。

这是功能,可能是由rsh行为的历史原因引起的。这是很合理的。大多数命令实际上不是交互式的,分配PTY也不是自由操作(这在20年前更为重要)。


资源问题似乎是合理的,但rsh由于该程序没有相应的选项,因此对它的注释不明确。
Thomas Dickey

我从未使用过@ThomasDickey rsh,但是肯定会有一些影响,不是影响选项,而是影响rshand rlogin(如果有命令)的行为。您不能使用rsh运行交互式命令(例如rogue(6)或vi(1));请改用rlogin(1)。
雅库耶

1

应该如何ssh判断您正在调用的命令是否是交互式的?

当您意识到自己可能正在登录运行非unix操作系统的计算机时,这一噩梦变得更糟。

没有简单的解决方案,必须将一种情况作为默认情况。


不知道 不知道 因此,我们有一个手册页来描述这些情况下的行为。
Jakuje
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.