[kwlug-disc] Sharing desktop in Xubuntu

[unsolicited]

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

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

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?

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?

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

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?

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

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

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?

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

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

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.


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

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

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

[Anonymous ftp on the relaying server may be your friend here? Script 
calls for ftp download then runs that latest incarnation?]

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

Not in play. If such is present, it was present before call. Nothing 
here affects that. SSH server is of course appropriately secured and 
will never be running such bad things, anyways. Same is true on helper 
computer as helpee too, for that matter. Nothing here detects, corrects, 
or affects, anything already present.

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

You could actually make this more dynamic - at ssh in, send a temporary 
keyfile or something. Same benefits, no typing. Heck, put the temporary 
keyfile on the ftp - tie it to the helpee current public and internal IPs.


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

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.

Not sure what your additional complexity is practically buying you. The 
helper still has no exposed ports, only the helper destination IP can 
talk back on the link (while open / queued). The helper is either able 
to authenticate to the relay, or not, nothing to secure there, port / 
access / password wise, except the access to help needed queue 
authentication mechanism itself.

I'm also not sure what this VNC only solution buys you. File system, 
chat, vnc access functionality seem to surround the helping experience. 
Thus the attractiveness of TeamViewer.

Dynamic OpenVPN connections would take you to the same place, and bring 
all the advantages of your ssh with it. Further, if there is a static 
/30 net created between the two, the vnc invite can be passwordless 
scripted to go to the known other end of the vpn tunnel. (Assumption, 
only 1 person being helped at a time by a helper, thus their end could 
always be 192.168.123.1.) Permissions / passwords are inherent to the 
helpee clicking 'invite'. So could chat, for that matter, or any other 
useful tools that become apparent over time. All without additional 
scripting as the help environment evolves.

I guess this is also starting to sound like you're reinventing the 
wheel. (One more bit of custom code to maintain, let alone distribute.)

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

Also accomplished by browser access by local net to queue on relay. In 
that case, not even a need for access to the helper script - built in to 
the web page.

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

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

Nature of beast. You're also assuming the helper is competent to not 
inadvertently do damage. Nature of beast.

Avoid the helper account entirely and just reverse vnc only, avoid the 
account. The remote helper using the users own screen inherently uses 
that user's permissions / authority, and the helper need never know any 
of it. This is part of what I mean by complexity, what is it buying you, 
particularly if unique per help instance and so something to be scripted 
/ generated on the fly.

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

Since no port is open on the customer router, this is inherently true 
without further precautions on your part. The exception would be 
passwordless wifi at the customer end. Otherwise the hole is only 
locally accessible, and that local user will have to have shared things 
with them. If they do that, all bets are off - their problem and 
responsibility, not yours. With vnc invite, not even an x11vnc server 
running when out of help band.

 > - VNC and tightvnc are bandwidth hogs.

Nature of beast - send video at 60fps ... it happens. But only for the 
duration of the vnc session. Add the encryptions and you're making your 
problem worse.

 >    arbitrary SSH server on a customer machine and leaving it running by
 >    default exposes the customer to a lot of risk.

No. Maybe. The server itself running is not at risk - no port open on 
local router. If you also require port opening on router, then yes, but 
your solutions all intend to avoid that requirement. In that case, 
having a server running is not a significant risk. Passwords have to be 
shared to be successful. Let alone it does not need to be a daemon. 
Build in a popup if you feel inclined - ... <account> just remotely 
connected via <daemon>

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.

 > Also TeamViewer may have some
 >    code to detect commercial use (ie connecting to many different
 >    machines) and make you feel bad.

It does, actually ... free session always leave up an extra popup box on 
the screen to be acknowledged. Annoying. "Hopefully you appreciated our 
providing you with this free session." or something similar.

- I keep TeamViewer around for when things go wonky to reset vnc and/or 
openvpn. Then have to vnc back in to acknowledge the annoying popup.

This makes argument for OpenVPN. And vnc invites over that dynamic tunnel.

OpenVNC has a telnet facility as well. You can telnet to it to command 
line control sessions. For me 'status 3' is the useful bit. If a bit of 
httpd magic interpreted that, then a link of vnc://192.168.0.1:5942 can 
be generated for the helper to click on and magic happen. Script 
distribution and maintenance problem solved.


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