[kwlug-disc] Sharing desktop in Xubuntu

[Paul Nijjar]

On Thu, Aug 28, 2014 at 05:24:40AM -0400, unsolicited wrote:
> - You might not need the relay. OpenVPN has been astonishingly
> successful with NAT2NAT connections over UDP. Haven't tried it, but
> don't see why it shouldn't with vnc invites.

I have never gotten OpenVPN working without a server. Also, I neither
want to use a hardcoded OpenVPN shared secret nor a PKI
infrastructure. 

> > - 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).
> 
> ssh client only?

Yes. 

> Will this prevent the user from doing their own vnc solution? e.g.
> All my machines run vnc at home with access within the home. I
> expect many people do. (I too gave up on other vnc solutions in
> favour of x11vnc, server and client.) Port conflicts? Script doesn't
> get port as already in use?

I do not think this will inhibit people doing their own vnc solutions,
because the vnc server does not run unless the people initiate the
server. 

> If the two are already engaged in some chat mechanism, don't some
> chat mechanisms have the ability to send links / 'shortcuts'? The
> helper could just send 'cmdline' and the helpee just click it?

My model is people talking over the phone. But it is possible to send
scripts back and forth, I imagine. I do not think this solution is a
one-liner. 

> It would help your helpers if you could present this in a web page -
> they just hit refresh, click the link, and their magic is kicked in.
> K.I.S.S.?

Possibly. We can burn that bridge if it comes up. All of our CR
workstations run Linux, so access to SSH is pretty easy. 

> What are you buying but complexity by having the helpee type in the
> password? keyfiles? (Per user?) Agreement to be helped is
> sufficiently inherent to clicking the link?

I do not need to encode a password or authorized keyfile that (a)
never changes even if the key is compromised by some bad person and
(b) opens up access to my server. Instead the password is
dynamically created. 

There is no way I am doing per-user keyfiles, because we would have to
create (and store on the server) a separate keyfile for every single
Linux machine we sell. 

> 
> > - The customer script first makes an REVERSE ssh tunnel using
> >    something like the following:
> 
> Why not just have an accompanying ~/.ssh/ssh_config file with the
> redirect built in? or from the command line.
> 
> The command line in the link / script, anyways, no need for more. At
> the least you have 'ssh helpsite' in the link / script / whatever /
> somewhere, already. Be it config file or cmdline parameter, build in
> the redirect already?

Yes. The customer does not know that he or she is making a tunnel or
using a VNC server or anything else. The script I provide does all of
the magic for them. It probably opens a scary terminal window, but
that's about it. I intend to use zenity to prompt the user, so the
customer does not even need to interact with the scary terminal. 

> You could avoid the ssh and other user complexity entirely just by
> doing vnc invites. All the complexity stays on the helper end.
> (They're in need of help, less to go wrong at their end in
> delivering it.)

How do you do this when neither the customer nor the helper accepts
incoming connections?


> Following the above ... with ssh you have established permission to
> help, and that each end is really what it purports to be ... isn't
> adding later VNC passwords and so on just adding complexity without
> adding value?

Yes, we could potentially drop the VNC password if we so chose.
Personally I like the idea that the helper has to enter in something
to authenticate to the customer's machine, and that the customer has
the option of denying the connection until he or she reads the VNC
password to the helper. 

> > - Post profit, the helper closes the VNC connection. The customer
> 
> IIRC, there is an ssh option to auto-terminate when the last TCP
> connection terminates. Isn't there a utility ... portmap ...
> something ... anyways, it's an inetd equivalent that when receiving
> a call on a port triggers a program. Be it this (vnc connect request
> trigger the ssh call) or the ssh option, the closing of the vnc
> connection would trigger an auto-close of the ssh connection. No
> further user intervention required / script would continue as you
> describe.

Sure. I am willing to do something like this. 

> > - This does not require the customer to have root access or know the
> >    administration password.
> 
> Probably not helpful / useful. For the level of help where remote
> intervention is required, it's also probably going to need root.
> That the calling user does not have root knowledge, and authority to
> see the problem fixed, means you're probably not where you want to
> be.

This is sometimes the case, but not always. I have gotten several
support requests of the nature of "I have seen a scary error message
that I am unwilling/unable to copy exactly, and I want you to
interpret it for me."

> It is inappropriate that the helper know the root password. So if
> root is needed, they set up the <x>sudo call, and asks the helpee to
> type in the root password when prompted.
> 
> The customer not having the root password is probably not a positive.

The customer is allowed to have the root password (and the sudo
password), but it is not necessary to run the script. Even if people
have the administration password, leading them through the steps of
running a script as root is not that easy. 


> > - This does not require the customer to have any SSH authentication
> >    keys installed on his or her machine.
> 
> How is this a positive, vis a vis they have to have scripts,
> anyways, and without requires password entry by perhaps keyboard
> challenged end users.

The passwords will be pretty easy. 

SSH authentication keys can go stale. Dynamically generated passwords
don't go stale in the same way (because they are inherently stale, and
so there is no point in remembering them). 


> > - 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.
> 
> Call by IP instead of name?

Can't. We have a dynamic IP. 

> 
> For that matter ... are you going to have to create an update
> mechanism should details change? Server/key changes, script changes,
> so on?

Nope for updating the server IP. "sshserver.theworkingcentre.org" will
actually be a dynamic DNS address. 

Server key changes could be a big issue. That is something that we as
CR people will have to manage. 

There is some chance that the script goes out of date. Then we have to
get the new script to people, true, but there is a good chance we can
bootstrap if basic functionality works. 

> 
> > - This requires typing in one additional set of codes when compared to
> >    TeamViewer, but this should not be too much of a hassle.
> 
> Try to get to no codes - clicks only. K.I.S.S. The helpee is not
> exposed, no ports open. The SSH server is not exposed - secured. The
> helper is always going to the same local server, what benefit to
> unscripted passwords? Let alone ~/.vnccreds files?

Again, I like the idea of intentional user consent. 

> Sorry, feels like a lot of complexity here. Doesn't feel elegant.
> Something's missing.

You could be correct. I was excited that I could do this without
needing to have open ports on either the helper or customer computers. 
If you believe that vnc invites can do that then please share the
link. 

> Ideally you would want this central server with queues. Helpee
> clicks a link that then shows up in a queue on the central server as
> someone looking for help. Helper browses to screen on server with
> list of people looking for help, clicks 'help this person', and
> magic happens without further user intervention, either end.

I do not anticipate that much usage. We are not running a call centre.
This is for very occasional use. 

> > - I have not thought about this much, but it may be possible to extend
> >    this solution to the Windows machines we sell.
> 
> This is inherent. cygwin ssh and tightvnc on Windows, done.
> Eliminate ssh and cygwin goes away. Use ultravnc or others and ssh
> comes back in inherent to those apps. Let alone within vnc
> accounts/passwords. Built in to shortcuts under accessories / WChelp
> entries.

It is not inherent if I want to keep the open ports minimized. 

> It is not an unreasonable expectation on your part that users secure
> their homes.
> 
> > - 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.
> 
> WHA? You must be misunderstanding something. At the least, x11vnc,
> tightvnc have alwaysshare options. I don't understand your reference
> to the user's existing session. There is no existing session.

The existing desktop? My terminology is wrong.

I probably am misunderstanding tightvnc. Oh well. x11vnc works well
enough.

- Paul 

-- 
http://pnijjar.freeshell.org
Join us for Software Freedom Day on Sept 20: http://kwlug.org/sfd