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.
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.
(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.
Mass move of bugs RESOLVED->CLOSED following the release of openssh-5.5p1