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?

ssh pty

— Ron Vince
source

La réponse courte est "parce que ce n'est généralement pas ce que vous voulez".

— Celada

Je prédis que votre question sera modérée pour essentiellement demander un avis / faire une plainte. Mais retournons la question: pourquoi ssh devrait-il allouer des ressources tty alors que ce n'est pas nécessaire dans la grande majorité des cas? La VRAIE question est: pourquoi l'allocation force-tty n'est-elle pas une option de configuration pour que vous puissiez en faire une valeur par défaut ou spécifique à l'hôte?

— Otheus

@Otheus Il est une option de configuration. Vous pouvez définir RequestTTY yes(ou force) dans votre configuration.

— Jakuje

Euh en effet. Semble avoir été introduit en 6 mais buggé jusqu'à peu de temps après. J'utilise uniquement des distributions très anciennes. :)

— Otheus

Comment SSH peut-il savoir de manière fiable qu'un programme est interactif? Même toppeut fonctionner en mode batch.

— muru

Réponses:

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
$

— psmears
source

C'est un bon point que je n'étais pas au courant.

— Jakuje

@ThomasDickey: À peine ... la question n'est pas "quelle est la raison historique derrière le choix des développeurs de cette valeur par défaut", mais "pourquoi sshd ne peut-il pas utiliser un pseudo-terminal par défaut" (l'accent est mis sur moi, mais la formulation est plus ou moins directe de la question). Donc, la différence de comportement (qui briserait un certain nombre d'expressions idiomatiques de script) est pertinente, indépendamment de la façon dont les développeurs ont fait ce choix :-)

— psmears

@ThomasDickey: Avez-vous même lu la question? Où cela mentionne-t-il l'avis des développeurs?

— psmears

+1 souligne un avantage spécifique de ne pas utiliser de pty (autre que la performance). Vous pourriez toujours faire valoir que cela -tdevrait être la valeur par défaut et une option requise pour la désactiver, donc vraiment l'avantage de performance mineur est ce qui est le plus logique pour moi dans les cas où cela n'a pas d'importance.

— Peter Cordes

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

— Jakuje
source

Les problèmes de ressources sont plausibles, mais le commentaire sur rshest obscur car ce programme n'a pas d'option correspondante.

— Thomas Dickey

@ThomasDickey Je n'ai jamais utilisé rsh, mais il y a certainement une certaine influence, non pas dans les options, mais dans le comportement de rshet rlogin(s'il y a commande ou non). Vous ne pouvez pas exécuter une commande interactive (comme rogue (6) ou vi (1)) à l'aide de rsh; utilisez plutôt rlogin (1). .

— Jakuje

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.

— dmckee --- chaton ex-modérateur
source

Il ne sait pas. Ça ne peut pas savoir. Et donc nous avons une page de manuel qui décrit le comportement dans ces situations.

— Jakuje