• Launchpad Entry: shared-console

  • Created: 2009-08-27

  • Contributors:

  • Packages affected:

  • See also:


This specification details a system for providing support to a user on ubuntu by means of a shared console session. This could be used to remotely fix someone's X configuration.


Use Cases

user wants some interactive real time command line help with his Ubuntu computer. He is behind a domestic NAT firewall router (which he can't reconfigure) he has a dynamic IP address assigned by the ISP and he has no idea what it is. He has installed Ubuntu from the desktop CD with all the defaults. His computer is connected to the network but X might not be running. apt-get probably works. wget and curl certainly work.

expert knows what she is doing on the command line and can open a port on her firewall and map it to her computer. She knows her external IP address and probably has a DNS address mapped to it. She has been communicating with user over email/IRC/Twitter/real life and wants to see the situation for herself.

Whilst expert and user are being friendly and we can assume a certain level of trust, this doesn't go far. expert doesn't want to know or see user's password or have any lasting rights over user's machine. expert doesn't want to give user any rights over her machine. user wants to give expert temporary rights to co-type in a shell session. In that session sudo authority may be used, but user will type in the password, not expert.



The bits

  • ssh
  • sshd
  • screen
  • bash script to tie it all together
  • expert configures an account with ssh access but no rights to do anything, just to do a reverse ssh port mapping
  • user installs the application by apt-get or by downloading a script with wget, chmod +x and running it.

The script does the following

  • creates a temporary account on user's machine called support (by default)
  • a short random password is assigned to the support account
  • a detached screen session is started in the context of the support account
  • su support -c "screen -d -m"
  • the .bashrc of the support account is modifed so that on login it does screen -x (unless the $STY variable is set to indicate it is already in the screen session)
  • a reverse ssh tunnel is set up to expert's machine
  • an ssh session to support@localhost is started on user's machine so she can see the shared terminal
  • expert starts an ssh session to her localhost on the reverse port so she can see the shared terminal

both are now looking at the same terminal on user's machine running a shell under the support account, from here they can change to the user account and get sudo access.

support@usermachine:~$ su user

user types in his password

user@usermachine:~$ sudo nano /etc/X11/xorg.conf

user types in his password

If user is uncomfortable about what is being typed he can stop the session, or pull out the network lead.



Sometimes it is hard to see what a user is doing wrong remotely, they may be typing something incorrectly and getting unexpected results. It would be great to observe the screen directly.

Scope and Use Cases

While not always required, but in many cases they bring much better clarity to the scope and scale of the specification than could be obtained by talking in abstract terms.

Use Cases

  • a person is looking for support in a loco IRC channel and it would help if people providing support could see the screen and make changes.

Implementation Plan


Outstanding Issues

SpecRemoteConsoleSupport (last edited 2009-08-30 22:14:22 by alanbell)