Why doesn't sshd use a pseudo terminal when the ssh client's argument is followed by an interactive program?

Question

The normal way to connect to an SSH server is ssh username@ip_address. But a user may only want to run a program on the remote machine. So the program name follows after the normal argument which is ssh username@ip_address <program_name>. For example, ssh username@ip_address ls. That argument is fine except for interactive programs (that also accept user input as well as providing output) e.g. top. The output is

TERM environment variable not set.

which means no (pseudo-)terminal is attached between the sshd and top programs. The solution is to add argument -t where the whole command now becomes ssh -t username@ip_address top.

My question is why can't sshd by default also use a pseudo-terminal to communicate with non-interactive programs so there is no need to add the -t argument for interactive programs?

Answer 1

It's true that, as others have said, PTYs have a certain overhead - but the big reason for not using a PTY when running a remote command is that you lose information.

Normally, when you run a command remotely via ssh, the command's stdout and stderr streams are sent to the local stdout and stderr, which means you can redirect/pipe them separately - for example:

$ 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

But if you use a PTY, all output goes to stdout, because PTYs don't have separate streams for output/error:

$ 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

Manual page for ssh describes this:

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.

It is feature and probably caused by historical reasons of rsh behaviour. It is pretty reasonable. Most of the commands are really not interactive and it is not free operation to allocate PTY (which was more important 20 years back).

Answer 3

How is ssh suppose to tell if the command you are invoking is interactive or not?

This nightmare is made worse when you realize you could be logging into a machine running a non-unix OS.

There being no easy solution one case had to be the default.