Pourquoi sshd n'utilise-t-il pas un pseudo-terminal lorsque l'argument du client ssh est suivi d'un programme interactif?

La manière normale de se connecter à un serveur SSH est ssh username@ip_address. Mais un utilisateur peut seulement vouloir exécuter un programme sur la machine distante. Ainsi, le nom du programme suit l'argument normal qui est ssh username@ip_address <program_name>. Par exemple ssh username@ip_address ls,. Cet argument est très bien, sauf pour les programmes interactifs (qui acceptent également l'entrée utilisateur ainsi que la fourniture de sortie), par exemple top. La sortie est

Variable d'environnement TERM non définie.

ce qui signifie qu'aucun (pseudo-) terminal n'est attaché entre les programmes sshd et top. La solution consiste à ajouter l'argument -toù la commande entière devient maintenant ssh -t username@ip_address top.

Ma question est pourquoi sshd par défaut ne peut-il pas également utiliser un pseudo-terminal pour communiquer avec des programmes non interactifs donc il n'est pas nécessaire d'ajouter l' -targument pour les programmes interactifs?

Il est vrai que, comme d'autres l'ont dit, les PTY ont une certaine surcharge - mais la grande raison de ne pas utiliser de PTY lors de l'exécution d'une commande à distance est que vous perdez des informations.

Normalement, lorsque vous exécutez une commande à distance via ssh, les commandes stdoutet les stderrflux sont envoyés au local stdoutet stderr, ce qui signifie que vous pouvez les rediriger / diriger séparément - par exemple:

$ 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

Mais si vous utilisez un PTY, toutes les sorties vont à stdout, car les PTY n'ont pas de flux séparés pour la sortie / erreur:

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

La page de manuel pour sshdécrit ceci:

Lorsque l'identité de l'utilisateur a été acceptée par le serveur, le serveur exécute la commande donnée dans une session non interactive ou, si aucune commande n'a été spécifiée, se connecte à la machine et donne à l'utilisateur un shell normal en tant que session interactive . Toutes les communications avec la commande à distance ou le shell seront automatiquement cryptées.

Elle est caractéristique et probablement causée par des raisons historiques de rshcomportement. C'est assez raisonnable. La plupart des commandes ne sont vraiment pas interactives et ce n'est pas une opération gratuite d'allouer PTY (ce qui était plus important il y a 20 ans).

Comment est sshsupposé dire si la commande que vous invoquez est interactive ou non?

Ce cauchemar est aggravé lorsque vous réalisez que vous pourriez vous connecter à une machine exécutant un système d'exploitation non-unix.

En l'absence de solution facile, un cas devait être celui par défaut.