Suppose one is running an SSH session into a GNU/Linux box of a client and he asks you to see "what you are doing". How can you allow this other party to see what's going on in your session?


You could try using the "screen" command. This will allow you to run a multiuser session which 2 users can connect and share. First you'll need to set the suid bit. screen comes with it turned off, and it is necessary for multiuser mode:

sudo chmod +s /usr/bin/screen
sudo chmod 755 /var/run/screen

The first user connect, running

screen -S shared

The "-S" just gives the session an easy to use name. To allow multiuser access, use "CTRL+A" to run screen commands:

:multiuser on
:acladd otheruser

When otheruser connects over ssh, he just needs to run

screen -x firstuser/shared

to join the session

  • 2
    If either one of the parties is able to use su/sudo to become the other user then you don't need to to mess with the setuid or permissions at all. Just use su so both parties are using the same account. The first user runs screen, and the and then run screen -x. – Zoredache May 4 '10 at 23:44
  • It isn't explicitly stated in the answer, but the second user can only see what is running in the screen session; ie the first user has to be running screen before doing the "interesting" bit. Also if terminal sizes don't match, the second user's experience may be... interesting. – David Mackintosh May 5 '10 at 2:54
  • @zoredache: that way you can run into problems with tty permissions – ptman May 5 '10 at 4:36

Worked like a charm.

I also received an offline hint from a guy I chatted with proposing an alternate solution:

user wishing to share uses "w" to view where the other guy is working...

# w
 16:27:10 up 30 days,  8:37,  3 users,  load average: 0,99, 0,94, 0,89
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     tty1     -                26Apr10  9days  0.04s  0.01s login -- root
root     pts/0     15:31   54:29   0.04s  0.00s script
root     pts/1    16:21    3:29   0.05s  0.05s -bash

now that we now were the other guy is working, we issue this:

# script | tee /dev/pts/1 

This method has disadvantages to the one proposed by katriel, as it is one way only and if you forget to use exit to break the connection, the other pts keeps receiving data even if the user logs out of it, being a potential security threat. But I thought it was worth mentioning.

Anyway thanks to katriel and the others.


Just run a VNC server on your workstation and let him connect to that. Cheap and easy :)

  • VNC is fine for X sessions, but not for a console session. – Cristian Ciupitu May 5 '10 at 20:01
  • If your ssh client is launched from an X session, then it's no problem. – apenwarr May 7 '10 at 19:20

I have a small open-source project that (I hope) fills this need perfectly: Termbeamer.

It lets you start a terminal session and send it to one or more other people across the internet. It works from behind firewalls and NAT and has a remote-control option if you want to let the other person "drive" -- good for pair programming.


Apenwarr has a good suggestion, but I recently used TeamViewer for just this purpose. It's similar to VNC, but requires ZERO installation, on both ends. No server install, no client install required. It even does NAT traversal with no configuration... something that VNC can't do.


Try it, you'll fall in love.

  • Also, it costs a zillion dollars. – apenwarr May 7 '10 at 19:22
  • Also runs under Wine which runs under X. – Wranorn Sep 18 '15 at 19:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy