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?

ssh pty

— Ron Vince
fonte

A resposta curta é "porque geralmente não é isso que você deseja".

— Celada

Prevejo que sua pergunta será moderada por essencialmente pedir uma opinião / reclamar. Mas vamos inverter a questão: por que o ssh aloca tty recursos quando não é necessário na grande maioria dos casos? A questão REAL é: por que a alocação forçada-tty não é uma opção de configuração para que você possa torná-la padrão ou específica do host?

— Otheus 13/03

@Otheus Ele é opção de configuração. Você pode definir RequestTTY yes(ou force) na sua configuração.

— Jakuje 13/03/16

Er mesmo. Parece ter sido introduzido em 6, mas com erros até pouco depois. Eu só uso distribuições muito antigas. :)

— Otheus 13/03

Como o SSH pode saber com segurança que um programa é interativo? Even toppode ser executado em modo batch.

— Muru

Respostas:

É 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
$

— psmears
fonte

Este é um bom ponto de que eu não estava ciente.

— Jakuje 13/03/16

@ThomasDickey: Dificilmente ... a questão não é "qual é a razão histórica por trás da escolha desse padrão pelos desenvolvedores", mas "por que o sshd não pode usar um pseudo-terminal por padrão" (a ênfase é minha, mas o redação é mais ou menos direta da questão). Portanto, a diferença de comportamento (que iria quebrar uma série de idiomas de scripting) é relevante, independente de como os desenvolvedores fez essa escolha :-)

— psmears

@ ThomasDickey: Você já leu a pergunta? Onde ele menciona a opinião dos desenvolvedores?

— Psmears 13/03/16

+1 indica uma vantagem específica de não usar um pty (exceto desempenho). Você ainda pode argumentar que esse -tdeve ser o padrão e uma opção necessária para desativá-lo. Portanto, a menor vantagem de desempenho é o que faz mais sentido para mim nos casos em que isso não importa.

— Peter Cordes

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).

— Jakuje
fonte

As questões de recursos são plausíveis, mas o comentário sobre rshé obscuro, pois esse programa não tem opção correspondente.

— Thomas Dickey

@ThomasDickey Eu nunca usei rsh, mas certamente há alguma influência, não nas opções, mas no comportamento de rshe rlogin(se houver comando ou não). Você não pode executar um comando interativo (como rogue (6) ou vi (1)) usando rsh; use rlogin (1) em vez disso. .

— Jakuje 13/03/16

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.

— dmckee --- gatinho ex-moderador
fonte

Não sabe. Não pode saber. E, portanto, temos a página de manual que descreve o comportamento nessas situações.

— Jakuje 13/03/16