Por que o sshd não usa um terminal pseudo quando o argumento do cliente ssh é seguido por um programa interativo?

Question

A maneira normal de se conectar a um servidor SSH é ssh username@ip_address . Mas um usuário só pode querer executar um programa na máquina remota. Portanto, o nome do programa segue após o argumento normal que é ssh username@ip_address <program_name> . Por exemplo, ssh username@ip_address ls . Esse argumento é bom, exceto para programas interativos (que também aceitam entrada do usuário, bem como fornecer saída), e. %código%. A saída é

TERM environment variable not set.

que significa que nenhum terminal (pseudo-) está conectado entre os programas sshd e top. A solução é adicionar o argumento top , onde o comando inteiro agora se torna -t .

A minha pergunta é por que o sshd também não pode usar um pseudo-terminal para se comunicar com programas não interativos, então não há necessidade de adicionar o argumento ssh -t username@ip_address top para programas interativos?

    

Answer 1

É verdade que, como outros já disseram, os PTYs têm uma certa sobrecarga - mas a grande razão para não usar um PTY ao executar um comando remoto é que você perde informações.

Normalmente, quando você executa um comando remotamente via ssh, os fluxos stdout e stderr do comando são enviados para o local stdout e stderr , o que significa que você pode redirecionar / canalizá-los separadamente - por exemplo:

$ 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

Mas se você usar um PTY, toda a saída vai para stdout , porque os PTYs não possuem fluxos separados para saída / erro:

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

    

Answer 2

A página de manual para ssh descreve isso:

When the user's identity has been accepted by the server, the server either executes the given command in a non-interactive session or, if no command has been specified, logs into the machine and gives the user a normal shell as an interactive session. All communication with the remote command or shell will be automatically encrypted.

É um recurso e provavelmente causado por razões históricas do comportamento rsh . É bem razoável. A maioria dos comandos não é realmente interativa e não é uma operação livre para alocar o PTY (o que era mais importante há 20 anos).

    

Answer 3

Como o ssh deve saber se o comando que você está invocando é interativo ou não?

Este pesadelo se agrava quando você percebe que pode estar logando em uma máquina rodando um sistema operacional não-unix.

Não havendo solução fácil, um caso teve que ser o padrão.