[kwlug-disc] Sharing desktop in Xubuntu

[unsolicited]

On 14-08-28 06:09 AM, Paul Nijjar wrote:
> 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.

Then you need to look again, because you need neither. Examples abound.

>>> - 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 they're running vnc, your instance, and associated scripts and 
passwords, will fail, if same port.

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

And ssh brings what to the party?

>> 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.

Neither are in play, regardless.

> 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.

Not needed, and not so.

However ... arguably ... the mechanism need only be present for those 
who call for help. In essence, a help installation mechanism. (e.g. ftp 
/ script download, or something.)


>> 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 miss the point, the only necessary interaction is the clicking of 
the link. Further interaction brings nothing to the party. No 'scary' 
dialogues or need to type in cryptic hard to type passwords. xmessage 
could be used to say "You are starting a connection to <x> to get help. 
Click OK to proceed, Cancel to cancel." Done.


>> 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?

The helpee is initiating the connection (invitation). Therefore, no 
router ports to open.

It goes to the known server/port on the relay server you note creating. 
("Please come in. Waiting for someone to do so ...")

The helper too goes to the known server. ("I'm here to help.")

Connection established.

This could be OpenVPN, vnc gateway (various gateways will have more or 
less functionality, e.g. chat.)

> 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.

Have a think about your audience. There will be a class of users whom 
have the patience and inclination to google and tinker. Most will never 
use this service, some will be entirely satisfied by hints over the 
phone, e-mail of links, and so on. When they do call, they will 
certainly be able to handle this complexity.

Then there is the class of users without the inclination of the above. I 
would guess that these are likely the highest users of this remote 
service. If so, the fewest barriers between them and having their 
problem solved for them the better - more likely to get help. If they 
were inclined for complexity, they would be in the group above.

- what's running through my mind here are your comments surrounding 
biggest cause of unsuccessful Linux convert - lack of help after getting 
it home. (Which is exactly what you're trying to cover off here, I get 
that.) So, for this case, for your audience, is fewer barriers and 
complexity better?

>> IIRC, there is an ssh option to auto-terminate when the last TCP
>> connection terminates. Isn't there a utility ... portmap ...

> Sure. I am willing to do something like this.

I'm not quickly finding what I'm remembering. On ssh, perhaps something 
to do with master mode or gateway ports. Hopefully someone will chime 
in. Quick google took me to 
http://www.g-loaded.eu/2006/11/24/auto-closing-ssh-tunnels/ Ironic it's 
a vnc example.

For utilities, perhaps I'm thinking of netcat. Quick google revealed 
tcpxd for Cygwin. (Thus, Linux versions or equivalents will be out 
there.) I believe I'm thinking about a relay, or proxy, and probably in 
particular vnc proxies.

So, your central server would actually be a vnc proxy server. IIRC.


>>> - 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.

You're missing my point. For your first, the point is if they do need to 
know the root password, and don't have it - too late, support session 
was pointless. The customer darn well better have the root password! 
(Doesn't mean the caller does - different beastie.) My point was that in 
order to solve the problem may well need the root password, and the 
caller ready to type it in for the helper if needed - not that the 
script would need it. And finally, if the caller does not have the root 
password, is this caller authoritative for this customer's computer, and 
if not, you should have zero involvement. Don't be messing with someone 
else's machine without their authority, and ascertain that your caller 
has such authority. (e.g. ("DAD! ... tell them it's ok for them to help 
me!") One way to reasonably do that is for them to demonstrate they have 
the root password. Not saying you need them to prove it up front, merely 
that if they or someone local to the machine doesn't have it to hand if 
you need it (and during a support call is not the time to establish it), 
many of your support calls will be unresolvable - causing frustration 
all around. And likely resulting in the customer walking away from Linux 
- which is one central point of what you're trying to avoid / why you're 
doing this.

>>> - 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.

Doesn't answer the question.

> 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).

Same is true for dynamically generated keyfiles.

>>> - 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.

Then stop, do not pass go. Why should any customer have faith in any 
organization that can't prove it isn't a fly by night mickey mouse 
organization by having a public registered static IP?

Remember, it is only the relay machine that needs the static ip. You 
have webservers, certificates, therefore static ips. And the load on the 
relay should be minimal. Even if that machine merely relays internally 
to a vnc gateway.

For that matter, the relay machine need not even be on your local net. 
In essence it's just a directory service.

>> 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.

Again, the user has given consent by clicking 'Help!' Let alone, they 
probably won't do so until so directed over the phone.

>> 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.

I get that - there's the whole "this is mysterious and I don't 
understand it, but seems useful and worth learning about" factor. Let 
alone the feeling afterwards of "Hey, I figured it out!"

As for links and principles, I gave prior. You want a vnc gateway for 
simplicities sake. Granted: elements of surrounding discussion bring 
consideration to that 'simplicity'. e.g. Chat. And some clients have ssh 
functionality built in. vnc passwords always go encrypted, little value 
of encrypting session - if you have a MITM you have other problems in 
play, encrypting or not that session doesn't change that.

Quick google reveals as promising:
- 
http://deranfangvomende.wordpress.com/2009/06/25/the-holy-grail-of-vnc-vnc-gateway-including-java-client-fully-contained-in-port-443/
- http://ronadinihari.blogspot.com/2013/05/ubuntu-vnc-gateway.html
- https://sourceforge.net/projects/vncgateway/

>> 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.

You are putting in a lot of work, central development, maintenance, and 
distribution, user communications (both ends) for occasional use. 
Especially if you will be preinstalling things. i.e. Past results do not 
predict future performance - things could take off. Learn /set up  / 
maintenance 'free', once, get on with your day?

>>> - 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.

Not what I meant. If your Linux solution works in the way that you want 
without open ports, then the solution will be inherently applicable to 
Windows OS as equivalent tools exist there. Such as the above.

>> 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.

Ah. Still no - DISPLAY=:0

The whole point (my mind) of vnc is to see the existing session. I have 
seen what you talk about though - usually resulting from playing / 
trying to figure it out. Then I get baffled when after a reboot (clean 
solution implementation post figuring exact steps out) everything works 
as intended (1 X session, now being viewed) - so why did I just spend 
hours wrestling with a suddenly created 2nd x session.

Also, it's hard not to get distracted by the references to virtual vnc / 
x sessions.

VNC solutions will all work against X display 0. Even if sometimes that 
doesn't appear to be true. (It is / was the original point of it all.)

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

You misunderstand what I meant. The tightvnc options for encoding within 
x11vnc have done well for me. I too ditched the tightvnc linux client in 
favour of x11vnc. [Note: Primarily because of command line availability 
and ease of instantiation at boot. Even wrote scripts for my ease of 
access to remote machines. However, for a user implementation of vnc, 
e.g. Son helping Dad remotely, a GUI vnc implementation would be 
preferred. For the few times used.]

- regardless of the the customer version of vnc used, there should be an 
icon they can right-click and eject. (And standing instructions - pull 
the network cable if you become concerned.) And any such vnc should have 
right click and invite in it. (Called differently sometimes, e.g. 'add 
remote user'.) Your solution should work regardless of the remote 
version of vnc used, not depend upon x11vnc (but could, given preinstall 
- only saying it shouldn't get in the way of a new user following 
standard documentation.) Inherent to the act of inviting is consent - 
but the invite should go to a known name. In this solution, that name 
could be dynamic.

On the windows side, only, was saying tightvnc has been my winner / go 
to piece of FOSS for a very long time. Haven't much looked at things for 
years, but I understand ultravnc and tigervnc have come along since and 
(may) bring other user useful aspects to the party, windows side, such 
as ssh tunnelling built in, and/or (local?) account validation.