[kwlug-disc] Sharing desktop in Xubuntu

[Paul Nijjar]

On Sun, Aug 24, 2014 at 06:05:30AM -0400, Paul Nijjar wrote:
> 
> We are doing a refresh of our installation mechanisms at Computer
> Recycling. One thing I would like to support is being able to securely
> help people with their Linux installs remotely. The best solution I
> know of is proprietary: TeamViewer, which has the following
> advantages: 
> 
> - Once TeamViewer is installed on the client, it is easy for customers
>   to share their desktops. They just run the program and tell us the
>   access code. 
> - The program is only running when people need support.
> - From what I understand, communications are encrypted.
> - The users do not need to forward ports or expose anything on the
>   Internet.
> - The technician is not bound to using any particular machine for
>   seeing the remote desktop connection -- anything which supports the
>   TeamViewer client will work.
> - If necessary the technician can take control of the customer
>   desktop. 
> 
> I would like to find something FLOSSy that comes close to this
> functionality. I know some of you have this issue as well, so maybe
> some of you have solutions I can steal. But the problem seems more
> difficult than it looks. 

Found it! Unsolicited and Cranky pointed me towards the solution in
different ways. 

The answer is outlined here: 

http:/www.karlrunge.com/x11vnc/faq.html#faq-firewall-out

I am using the "SSH solution"

- Set up an SSH server somewhere on the Internet (which I plan to have
  in-house, on an isolated subnet with restricted access). Let's
  call this "sshserver"
- Make a "helpme" account on this server that allows SSH tunnelling
  but no interactive shells.
- Make a "helper" account on the server that is allowed interactive
  access.

The basic idea is then as follows: 

- The helper and customer are talking on the phone (or through a chat
  program, or whatever). 
- The helper decides that remote connection is a good idea. 
- The helper SSHes into sshserver and a script enables the helpme01
  account and sets it to a random, easy password (say "12345".) 

- On the customer machine, I have x11vnc installed, and ssh, and some
  script that the customer launches as a regular user (which still
  needs to be put together, but most of the components are there). 

- The customer script prompts the user for the helpme account SSH
  password. The helper tells the customer this password, and the
  customer types it in.

- The customer script first makes an REVERSE ssh tunnel using
  something like the following: 

  sshpass -f /tmp/easysshpassword ssh -oStrictHostKeyChecking=no -t -R 56733:localhost:5900 helpme01 at sshserver.theworkingcentre.org

  where /tmp/easysshpassword is the easy SSH password that was prompted for.
  (I could also do this using the commandline without an "sshpass"
  command, but commandlines are kind of scary. This needs some
  refining.) 

- Now the customer script generates a random, easy VNC password and 
  starts the x11vnc server to share desktops: 

  x11vnc -display :0 -passwdfile /tmp/easyvncpassword -ncache 10 -speeds modem 

  (-speeds modem can maybe be eliminated. It saves a lot of bandwidth,
  but x11vnc is supposed to be smart about this. This connects x11vnc
  to port 5900 (the default VNC port) on the local computer, which
  then is forwarded via SSH to the sshserver machine.) 

- The script displays the easy VNC password on the customer screen.
  Now the customer can read that easy password and transmit it to the
  helper. 

- The helper now starts a LOCAL tunnel to the ssh server on his or her
  desktop: 

  ssh -t -N -C -L 5900:localhost:56733 helper at sshserver.theworkingcentre.org 
  (this can be in a script, probably.) 

- Now the helper connects to the customer VNC computer using the
  tunnel: 

  vncviewer -bgr233 -nojpeg localhost

  This runs the viewer in 8 bit colour, which seems to be much less
  bandwidth intensive than other things I tried. Again, it is
  connecting to port 5900 on the helper computer, which is tunnelled
  to 56733 on the SSH server. 

- The helper is prompted for the easy VNC password and types it in. 

- Profit!

- Post profit, the helper closes the VNC connection. The customer
  script kills its tunnel and the helper script closes its tunnel.
  Then the SSH connection on the helper computer either disables the
  helpme account or changes its password to something difficult.


Analysis
--------

- This does not require the customer to have root access or know the
  administration password.
- This does not require the customer to have any SSH authentication
  keys installed on his or her machine. 
- Disabling the StrictHostChecking is kind of scary, but I figure that
  since this interaction is mediated by a conversation it should be
  relatively okay most of the time. A MITM attack is certainly
  possible, though.
- Neither the client nor the helper need to have any ports open on
  their computers. Only the SSH server is exposed, and it is exposed
  in a relatively limited way. (Plus I can put it on a DMZ-like
  subnet.) 
- Generating new SSH passwords for the helpme account means that even
  if there is spyware and keyloggers on the customer computer it will
  not be able to break in on subsequent attempts. It also means that
  every customer types in a unique code. 
- This requires typing in one additional set of codes when compared to
  TeamViewer, but this should not be too much of a hassle. 
- The helper does not need to be on any particular computer to help
  the user, so long as the helper has access to the helper script. 
- I have not thought about this much, but it may be possible to extend
  this solution to the Windows machines we sell. 
- I kind of have to trust that the people using the helper account are
  not malicious. I wish I could tell SSH to allow different users from
  different addresses. I have to think about how to lock down the
  helper account further. 
- I think that when the customer is not seeking help then there is
  nothing extra running on his or her computer, so adding this remote
  desktop solution should not make security worse. (Of course, if
  somebody breaks in and discovers that x11vnc is available, then the
  user could be in trouble. That is another reason not to run an SSH
  server by default.) 
- Currently I am doing everything over port 22 on the SSH server.
  This will probably change.

Other alternatives
------------------

I spent way too much time looking for alternative solutions, and
learned a few lessons. 

- VNC and tightvnc are bandwidth hogs. 
- The NX family of solutions is better on bandwidth, and one of them
  (in particular x2go ) was my first choice. The big problem is that they
  have helpfully integrated SSH into their products, and the x2go
  server (ie the customer computer) needs an SSH server running in
  order to be accessed. That is a dealbreaker; installing some
  arbitrary SSH server on a customer machine and leaving it running by
  default exposes the customer to a lot of risk. 
- The regular vnc server (and tightvncserver) want to create a NEW
  session for you to remote into, rather than sharing the user's
  existing session. That is why you need something like x11vnc, which
  shares the EXISTING session. 
- Technically TeamViewer is free for noncommercial use, so maybe we
  could install it on our machines. But that does not feel good, since
  we do sell these machines for money. Also TeamViewer may have some
  code to detect commercial use (ie connecting to many different
  machines) and make you feel bad.