[kwlug-disc] Sharing desktop in Xubuntu

[unsolicited]

Multiple issues going on here. Sorry, I know you despise such long 
answers, however, you ask a very non-trivial and non-simple question. 
Especially as ethics come into play.


Assumption (clarification appreciated): Many clients possibly supported 
by many admins (from various physical locations). e.g. Helpers would 
normally be volunteers within the working centre, but could be them from 
home, and in a pinch Paul from home helping Charles at home, or vice 
versa. [Although arguably these very trusted helpers, Paul and Charles, 
could be required and are capable of jumping through more hoops than the 
usual, e.g. command line use / ssh somewhere with a port redirect first 
before proceeding to support.]


 > On Sun, Aug 24, 2014 at 08:40:31AM -0400, Khalid Baheyeldin wrote:
 >> There is also krfb, which is KDE's remote desktop sharing solution,
 >> using VNC.

RFB is an X thing. Should be clients (er, servers) for most any 
platform. I believe vnc solutions are riding on top of that, at least in 
Linux solutions. (Paying attention to 5900.)


rdc (Windows desktop sharing, with several Linux server/client 
equivalents) appears to bring authentication with it, unlike vnc 
(although various vnc flavours can bring authentication but will require 
additional installation fiddling). My sense of kvm et al's use of rdc 
over RFB is because of this. I don't know that this brings anything to 
your (Paul's) particular party at this point in this solution, unless 
you deem it appropriate that any supporter must know/have a login 
(authentication) to the client before being able to support. (Client 
assurance that the person coming in to help is indeed the expected 
party.) e.g. login: workingcentrehelp, password: known, before being let 
in. (Problem, passwords will get out eventually, so it becomes debatable 
how 'secure' this mechanism is. Albeit, customer 'reassuring'.)


 > - Once TeamViewer

IIRC, I suspect such use of TeamViewer violates their free / personal 
use policies (up to 5 clients?). Your clients would be OK, but not your 
admins, I expect. I'm guessing there also becomes some additional 
fiddling for each and every client/supporter combination, if only at 
support time.

LogMeIn-Hamachi would also seem a viable alternative - has worked 
flawlessly for me until I stopped using them as they stopped being free. 
I expect working centre would need a license (same as TeamViewer above), 
but in either case you may get it free, given the nature of your 
'business'. LogMeIn-Hamachi, at least, degrades rather nicely / 
seamlessly. i.e. Both require connection to server (essentially merely 
saying "I'm over here."), but attempt to renegotiate direct connections 
that no longer go through that server during live support. And if it 
can't get it it continues to relay via that server. Slower in that case, 
but it's better than driving to Acton, and may let you figure out what's 
what to kick in the direct connection. (This gets around potential 
configuration issues, and some carrier's hop between you and them being 
down.) IIRC, you can bind each client to a supportee 'network', and each 
helper to a supporter 'network' and avoid the per client/server combo 
configuration / setup.

In both cases, you are exposed to a potential MITM attack. Your comfort 
depends upon how much you trust the serving organization.


Customer assurance 1 - one thing to decide for yourself is ... should 
you require that a customer only be asked to go to a known address? e.g. 
If vnc invite, invitation be to help.workingcentre.org, not just any old 
willy nilly address. [Personally, I think so.] vnc invite will maintain 
no need for the client to open up ports, but you will have to - which is 
probably entirely appropriate. Clients are being asked to then go to a 
known 'destination' - they know who to pin the blame on, and fears that 
the wild internet is attacking them alleviated.


Customer assurance 2 - another thing to decide for yourself is ... 
should you require that supporters be required to authenticate against 
-your- own help mechanisms? Team viewer credentials can presumably be 
copied by anyone to anywhere - including that support volunteer who has 
left, or been found to be doing inappropriate things. As could any other 
solution, I suppose. Requiring that a supporter pass through, and be 
authenticated by, your inhouse gateway is probably a reasonable thing. 
Let alone, client/server support becomes simplified in the sense that 
the client need only allow one destination, not every possible 
supporters end point. This also enables the client side to be a button, 
desktop icon, menu choice, whatever - no typing of address.

If you agree that supporters must pass through your control point, then 
you are talking about a vnc gateway. (This probably also creates the 
possibility of asking for help from the first available supporter logged 
in / queued up to provide support. Many clients could be asking help 
from many supporters, and the gateway could match the two on some basis. 
Round robin, whatever.)

In any of the above solutions, chat should also be possible. Avoiding 
the need to be on the phone with them at the time. But then this brings 
along complexity, e.g. not just a 'remote support' button, but a 'chat' 
button, and something automated to pop up on the client machine when the 
supporter first chats. "How can I help you today?", or "Is there 
anything else I can help you with?" [It is also arguable that you have 
some sort of tracking mechanism - this year we helped 456 clients ... 
donate today!]

You want the vnc invite mechanism. Probably many apps to do it. Myself I 
alias vnclisten to "alias vnclisten='echo -e 
"\n****************************\n*** Press F8 for options.*** 
\n****************************\n" ; xtightvncviewer -listen -shared 
-encodings "tight copyrect hextile zlib corre rre raw" -bgr233 -depth 8 
-compresslevel 1 -nojpeg'"

When I'm talking to someone and want to help / see their screen I 
'vnclisten' in a shell and have them vnc invite mydynamic.ipaddress - 
once they do, up pops their screen on mine.

You would do the same, but in your case it would be to the designated / 
known / trusted help.workingcentre.org name.

I Googled 'Linux "vnc gateway"' and see lots of pointers towards such 
beasties.


Not opening up a designated port at working centre end would essentially 
be unethical, IMO. Clients should have some sense, some reassurance, 
some confidence, some trust that what they're being asked to do is 
appropriate and reasonable. Much like telling them to make sure it is a 
trusted merchant, with a lock icon in the browser, before giving up 
their credit card info. Or telling them to trust the sender before 
opening up that e-mail attachment.

Asking them to let someone in to remote control their computer is much 
the same thing. Particularly as they cannot appreciate the potential 
security risks they are exposing themselves to. e.g. If you can vnc, for 
all they know you could ssh - at least with vnc they can see what you're 
doing. Hopefully your client setup does not allow the supporter to lock 
the client out of their own keyboard. And you include notices that if 
something doesn't look right, pull the Ethernet cable.

Given the ubiquity of vnc, and particularly the significant speed 
improvements using the tight protocol, (let alone 256 colours max,) 
that's what I would do. Certainly it's a lighter touch than OpenVPN, 
TeamViewer, or LogMeIn-Hamachi. However, once you add chat, or central 
logging, or if there is any advantage to OpenVPN in your use case, then 
you may have more to do / decide beyond vnc. e.g. You may want to create 
an anonymous ftp server at the same time. e.g. So supporters can pull 
down trusted scripts, files, docs, whatever, without further logging in 
or additional connectivity mechanisms hassle. (Which using OpenVPN out 
of the gate avoids. You may still use vnc, but some simplicity may occur 
as now you are already travelling over a trusted connection.)

In any case, clients to connect to a known name / ip address / service / 
gateway. And supporters to log in to it. Audit trail.

Googling '"best practices" "Linux" "remote support"' was also interesting.

CDN$0.02


On 14-08-24 06:05 AM, 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.
>
> For example, in a previous KWLUG presentation Gordon Dey said that he
> opens up SSH on the computers he takes care of, and uses some kind of
> dynamic DNS thing to connect into those computers when he needs to
> connect in. That is not a terrible solution, but it does not work for
> us: it essentially makes a backdoor that could be exploited, and we
> are not doing full-time systems administration for every machine.
>
> Here are some of the things I have been thinking of:
>
> - There is a program called pigterm (http://pigterm.sf.net) which uses
>    XMPP to establish terminal connections between two computers. This
>    might work if we establish a Jabber server someplace (which I guess
>    we could, since we have a Linode).
>
> - Similarly, GNOME supposedly supports desktop screen sharing via its
>    Empathy client, but that does not work for us because we typically
>    are not installing GNOME on client machines.
>
> - There is some Chrome extension called "Chrome Remote Desktop" which
>    would require installing Chromium and the extension on these
>    computers. This might be the best alternative, but Google creeps me
>    out.
>
> - There is some concept called "Reverse VNC" which allows the
>    customer's computer to make an outgoing connection to the technician
>    machine, and then the technician machine can see the customer
>    computer. There is a program called x11vnc which supposedly makes
>    this easier. But this requires us to open up some port on our
>    network, which is suboptimal for us.
>
> - I keep thinking vague fuzzy thoughts about SSH tunnels. I could
>    potentially install a public key for some server on each client
>    machine, and then when people want support they could click a
>    shortcut that would make an SSH connection to a server. Either this
>    means opening up a port on our network again, or we have to use an
>    external server like our Linode to serve as a broker (after which it
>    would hopefully make a direct connection between us, which is even
>    vaguer and fuzzier to me).
>
> - Drawing on another KWLUG presentation, maybe we set up a
>    BigBlueButton server, which supports desktop sharing. But
>    BigBlueButton has very high bandwidth requirements, which we cannot
>    provide. Also the client sharing the desktop needs Java installed.
>
> I really ought to be writing out this email AFTER I have come up with
> a well-tested solution, but I am hoping that somebody else has solved
> this problem for me already.