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

A maneira normal de se conectar a um servidor SSH é ssh username@ip_address. Mas um usuário pode querer apenas executar um programa na máquina remota. Portanto, o nome do programa segue 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 e também fornecem saída), por exemplo top. A saída é

Variável de ambiente TERM não definida.

o que significa que nenhum terminal (pseudo-) está conectado entre os programas sshd e top. A solução é adicionar argumento -tonde todo o comando se torna agora ssh -t username@ip_address top.

Minha pergunta é por que o sshd por padrão também não pode usar um pseudo-terminal para se comunicar com programas não interativos, para que não seja necessário adicionar o -targumento para programas interativos?

É verdade que, como já foi dito, os PTYs têm uma certa sobrecarga - mas o grande motivo 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 comandos stdoute os stderrfluxos são enviados para o local stdoute stderr, o que significa que você pode redirecioná-los / 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 será stdoutenviada, 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
$

A página de manual para sshdescreve isso:

Quando a identidade do usuário é aceita pelo servidor, o servidor executa o comando especificado em uma sessão não interativa ou, se nenhum comando foi especificado, efetua login na máquina e fornece ao usuário um shell normal como uma sessão interativa . Toda a comunicação com o comando ou shell remoto será criptografada automaticamente.

É característica e provavelmente causada por razões históricas de rshcomportamento. É bem razoável. A maioria dos comandos não é realmente interativa e não é uma operação livre para alocar PTY (que era mais importante há 20 anos).

Como é sshpossível dizer se o comando que você está chamando é interativo ou não?

Esse pesadelo é agravado quando você percebe que pode estar fazendo login em uma máquina executando um sistema operacional não-unix.

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