Bug 1673

Summary: pseudoterminal option (-t) breaks standard out/error separation
Product: Portable OpenSSH Reporter: raker1000
Component: sshAssignee: Assigned to nobody <unassigned-bugs>
Status: CLOSED WONTFIX    
Severity: normal CC: djm
Priority: P2    
Version: 5.1p1   
Hardware: Other   
OS: Other   

Description raker1000 2009-11-20 21:32:59 AEDT 
When connecting to run commands, standard error ends up mixed with standard output when using the (-t) pseudoterminal option.
====================
Here's an example without pseudoterminal option where it is working correctly, and the error messages from the server are captured by fd2 on the client:
---
$ ssh user@server 'uptime ; ls -l /blah' > out 2> err
user@server's password:

$ cat err
ls: cannot access /blah: No such file or directory

$ cat out
 05:07:09 up 14 days,  1:40,  4 users,  load average: 0.01, 0.02, 0.00
====================
And here's an example with pseudoterminal option where standard error is mixed in with standard output, and the error messages from the server are captured by fd1 on the client. The only error message that went to fd2 was the error from the ssh client executable:
---
$ ssh -t user@server 'uptime ; ls -l /blah' > out 2> err
user@server's password:

$ cat err
Connection to elena closed.

$ cat out
 05:07:20 up 14 days,  1:40,  5 users,  load average: 0.01, 0.02, 0.00
ls: cannot access /blah: No such file or directory

====================
I tested this from solaris8 to solaris8, from solaris8 to redhat linux, and from ubuntu linux to ubuntu linux, several versions of client/server.
Comment 1 Damien Miller 2009-11-21 14:52:44 AEDT 
This is expected. When a pty is allocated, all of stdin, stdout and stderr point to the pty (see "ls -l /proc/$$/fd" on Linux). Being on the other side of the pty, sshd has no way to determine which fd the child process issued the write() to. Changing the fd allocation so that stderr was a pipe instead of a pty would be a significant departure from standard practice and would probably break quite a few things.
Comment 2 raker1000 2009-11-23 01:34:55 AEDT 
(In reply to comment #1)
> This is expected. When a pty is allocated, all of stdin, stdout and
> stderr point to the pty (see "ls -l /proc/$$/fd" on Linux). Being on
> the other side of the pty, sshd has no way to determine which fd the
> child process issued the write() to. Changing the fd allocation so that
> stderr was a pipe instead of a pty would be a significant departure
> from standard practice and would probably break quite a few things.


I see. I wasn't sure whether this was intended behavior. Thank you for
the prompt attention.
Comment 3 Damien Miller 2010-04-16 15:51:20 AEST 
Mass move of bugs RESOLVED->CLOSED following the release of openssh-5.5p1