How to reroute stdout, stderr back to /dev/tty

33,484

Solution 1

A command that should do literally what you asked for in (2) is

exec >/dev/tty 2>&1

But I suspect that your analysis of the problem is incorrect. It would be useful to see the output of ssh -v ... (where ... is whatever arguments you typed in your original ssh command).

Solution 2

The command:

ls -l /proc/$$/fd/{1,2}

will show you which files are open as stdout (file descriptor 1) and stderr (file descriptor 2).

Solution 3

An answer to your first question could be found in /proc/self/fd. It contains symlinks to the files (or other things, pipes, sockets, etc) that your bash instance is connected to.

root@mammon:~# ls -l /proc/self/fd
total 0
lrwx------ 1 root root 64 May 21 02:18 0 -> /dev/pts/3
lrwx------ 1 root root 64 May 21 02:18 1 -> /dev/pts/3
lrwx------ 1 root root 64 May 21 02:18 2 -> /dev/pts/3
lr-x------ 1 root root 64 May 21 02:18 3 -> /proc/15529/fd/
root@mammon:~# ls -l /proc/self/fd < /dev/null
total 0
lr-x------ 1 root root 64 May 21 02:18 0 -> /dev/null
lrwx------ 1 root root 64 May 21 02:18 1 -> /dev/pts/3
lrwx------ 1 root root 64 May 21 02:18 2 -> /dev/pts/3
lr-x------ 1 root root 64 May 21 02:18 3 -> /proc/15536/fd/
root@mammon:~# ls -l /proc/self/fd | cat
total 0
lrwx------ 1 root root 64 May 21 02:18 0 -> /dev/pts/3
l-wx------ 1 root root 64 May 21 02:18 1 -> pipe:[497711]
lrwx------ 1 root root 64 May 21 02:18 2 -> /dev/pts/3
lr-x------ 1 root root 64 May 21 02:18 3 -> /proc/15537/fd/
root@mammon:~#

In the first example, you can see the first 3 file descriptors (which are the standard output, input, and error, respectively) all point to my pseudo-terminal /dev/pts/3. In the second example I've redirected the input to /dev/null, so the standard input file descriptor points to /dev/null. And in the final example I've sent the output of ls to cat through a pipe, and the standard input file descriptor reflects this. As far as I know there is no way to find which process has the other end of the pipe. In all examples there is the fourth file descriptor that represents the handle that ls has for reading /proc/self/fd. In this case it says /proc/15537 because /proc/self is in fact a symlink to /proc/pid where pid is the PID of the process accessing /proc/self.

Solution 4

It can only be done if your longing shell is started with a pipe to tee command with another console as a parameter.

Let me explain.

If you are logging in /dev/tty1 and someone else is logging in /dev/tty2. If you start your shell (bash) by following command all the STDOUT/STDERR will be rerouted/copied to another shell (/dev/tty2 in this case).

bash 2>&1 | tee /dev/tty2

So, someone sitting in /dev/tty2 will see all of your activity.

If someone logins shell is /bin/bash 2>&1 | tee /dev/tty2 instead of /bin/bash It'll happen every time he logs in. But I am not sure login shell can be set that way.

If someone reroutes all the output of your shell this way you can check it just by checking if any tee is running in background.

ps ax | grep tee

This will output something like

tee /dev/tty2
Share:
33,484
Sergey
Author by

Sergey

Ruby / RubyOnRails programmer from Minsk, Belarus.

Updated on July 09, 2022

Comments

  • Sergey
    Sergey almost 2 years

    I just ssh-ed to some remote server and found that stdout and stderr of all commands/processes I am trying to run in bash is redirected to somewhere. So, I got following questions

    How to detect:

    1) Which file stdout, stderr is beeing rerouted in Linux?

    and

    2) And how reroute by default stdout and stderr back to /dev/tty?

    Thank you in advance.