Skip

PPP dialup, dynamic DNS and Teamviewer
February 8, 2012 7:01 PM   Subscribe

Dynamic DNS services, PPP dialup and remote support for a technologically un-savvy relative.

Remote access scenario:

I have a technologically unsavvy relative for whom I am setting up a new desktop PC. Pretty much all they care about exists within a web browser - Gmail, Facebook, misc web browsing, etc. We are setting them up with a new basic slimline system based on the AMD E350 APU and Xubuntu 11.10. They are fine with the Xubuntu user interface, and actually less confused by it than by Gnome3, Windows 7, or whatever. It's close enough to the 2000/XP UI they are accustomed to for everyday basic use.

Various things have been added to the basic Xubuntu desktop, like Adblock Plus for firefox, Thunderbird setup to automatically grab their gmail via IMAP/SSL, Pidgin set to remember their gmail/google talk account and automatically login, skype set up the same way for their skype account/chatting (did you know that skype voice calls actually do work on dialup, if you're not trying to transfer anything else across the network connection at the same time? It's about 34 kbps UDP each way).

Periodically I would like to be able to remotely access the system to verify that it is automatically updating itself correctly and has not become screwed up in some way. This is complicated by two things:

1) Their only possible method of net access is via v.92 PPP dialup. I believe their account is not "unlimited", it's dial on demand, they have a quota of something like 6 hours usage/day. They are accustomed to disconnecting when not using the PC.

2) The last time I checked, their dialup ISP assigns addresses which are behind a pretty restrictive NAT. Any software on the PC that makes an outgoing connection first works okay, but things like RDP and VNC which need ports forwarded are pretty much a non starter. We have verified that TeamViewer does function correctly (of course, slowly) from their dialup connection.

3) Finding their IP might be difficult to walk them through on the phone.

I've installed the No IP Dynamic DNS ubuntu client on the system and set it up with a hostname.zapto.org assignment. The NoIP client is set to start when the system is booted. This appears to be working correctly with NoIP's back-end and resolving the system's hostname.zapto.org A record to whatever IP address the system is presently on.

Does anyone foresee issues with this setup? For remote support, all I need to do is have the person at the PC start the Teamviewer client and read me the current access numbers, and I theoretically should be able to start a (very slow) 8-bit colour Teamviewer session to the system. Any other ideas for dynamic DNS are also welcome!
posted by thewalrus to Computers & Internet (12 answers total)
 
The NoIP client is set to start when the system is booted.

Will they even have an external IP on boot, if they're using dialup?

Finding their IP might be difficult to walk them through on the phone.

I've had success just directing people to http://whatismyip.com/
posted by pompomtom at 7:11 PM on February 8, 2012


I think you can come up with a much simpler, faster, and more flexible solution than Teamviewer.

Have a look at Reverse SSH Tunneling. You should be able to put together a script that someone on the remote end starts instead of Teamview which uses SSH to connect to your machine and forward the appropriate ports so you can SSH/VNC/RDP/X11 back to it.
posted by RonButNotStupid at 7:16 PM on February 8, 2012


Here's a much more detailed explanation of how to set up a reverse ssh tunnel.
posted by RonButNotStupid at 7:20 PM on February 8, 2012


Ack. I should have read it more closely. You do not need a middle machine if you have someone on the remote end initiating the SSH session to your computer.
posted by RonButNotStupid at 7:21 PM on February 8, 2012


Definitely install openssh-server, set it to require a to key login, add a user for you, add that user to sudoers, and copy your main machine's key over. ssh is the ultimate wrench: you can use it to copy files, fix their Teamviewer install, etc. This will save you in the event that something goes wrong with the normal procedure. I would go so far as to write a tiny script to ssh to your computer/server and open a reverse ssh tunnel; you can have them double-click that if something goes wrong with ddns, etc.
posted by introp at 7:51 PM on February 8, 2012


I've had success just directing people to http://whatismyip.com/

Google just tells you now.
posted by empath at 11:23 PM on February 8, 2012


For remote customer support, I have a headless Debian box at home that's always on, a NAT rule in my router that maps a completely bogus port on my public IP address to port 22 on my Debian box, and a dyndns.org account that my router updates with my public IP address whenever that changes.

On that box I've created a user account called support whose login shell is set to /usr/bin/cat and whose password is disabled.

For customer Debian or Ubuntu boxes, I make sure vino is installed and enabled, then create a launcher on their panel or desktop called "Support hotline" that runs the command
ssh -p 26837 -R 9900:localhost:5900 -R 9901:localhost:22 support@myhouse.dyndns.org
in a terminal, with a tooltip comment that reads "Make a secure connection to flabdablet's computer that he can use to remote control this one. Please call first on (my phone number)."

I then open a terminal and do
ssh-keygen -t rsa
ssh -p 26837 mylogin@myhouse.dyndns.org 'sudo tee -a ~support/.ssh/authorized_keys' <~/.ssh/id_rsa.pub
to allow them passwordless access to the support account on my home box.

So it doesn't matter what kind of NAT the customer machine is hiding behind, and I don't need to expose any kind of Internet-facing service port on it; once they launch "Support hotline" there's a tunnel from port 9900 on my headless box to the VNC port (5900) on theirs, and another from 9901 on my box to the ssh port (22) on theirs.

All I need to do to get remote desktop access is click on a launcher on my own laptop that runs a VNC client aimed at port 9900 on my headless box. I can also get a shell with ssh -p 9901 theirusername@myheadlessbox.lan (though this will usually require removing other people's overlapping entries from the .ssh/known_hosts file on my laptop).

This works well. You'd probably want to wind back the quality on your VNC client pretty savagely for doing it over dialup, though.

I've also got the same kind of setup on a few customer Windows boxes using PuTTY and UltraVNC (which I install as a system service and leave running, but set to accept only loopback connections). The "Support hotline" shortcut I create on Windows actually invokes plink from the PuTTY suite rather than PuTTY itself. Sending a mouse click to a PuTTY window via a tunnel managed by that same instance of PuTTY causes a deadlock; this doesn't happen with the console window that opens when plink is invoked.
posted by flabdablet at 1:27 AM on February 9, 2012


Oh, and you can do all of that without the headless box; just create the support account on your own laptop instead of a headless middleman, and when the tunnel comes up you just VNC to localhost::9900 instead of headlessbox.lan::9900.
posted by flabdablet at 1:31 AM on February 9, 2012


You can manage to set up a SSH tunnel if you have a public IP address yourself or access to a machine that does. I've done this but this has turned out difficult. The problem is that you need a nice GUI, which no one has written yet, and that to circumvent a NAT, some sort of trickery or third-party server is required.

Perhaps I didn't read your post closely enough, but are there any reasons not to use Teamviewer? You say that you have verified that Teamviewer works. It likely uses a more compact desktop-sharing protocol than VNC, works even if both parties are behind a NAT and is extremely user-friendly: just have them start the program from the menu and read the number to you. As far as I know, there is a Teamviewer version for Linux. It's not free software, alas.
posted by faustdick at 3:56 AM on February 9, 2012


My remote technical support work for relatives has become so much easier since I learned about Join.me. I don't think it matters if they are behind anything strange or ultra secure - as long as you have someone on the client side to start it up and give you control, that's all you need. (No DynDNS/etc.. I've disabled all of it at my Mom's house because it's not needed anymore)
posted by getawaysticks at 9:33 AM on February 9, 2012


join.me doesn't have a Linux option though, does it?

The problem is that you need a nice GUI, which no one has written yet,

All that my users need to do is double-click a desktop icon or single-click a panel one, then click "OK" in a popup requesting authorization for remote desktop control. Why would anybody need more GUI than that?

and that to circumvent a NAT, some sort of trickery or third-party server is required.

The customer machine is initiating a ssh session to my server, not the other way around. So provided the NAT and dynamic DNS stuff is set up properly at my end (which is plenty easy to do for anybody skilled enough to offer remote support in the first place) there's no need for middleman servers and no need for any special network config on the customer side.

The ssh -R 9900:localhost:5900 option means that once the ssh connection is up, any connection I make to port 9900 on my end appears as a connection from localhost to localhost port 5900 on the customer machine. There is no requirement for initiating other network connections from my end to theirs.

In fact their VNC server can be configured to accept connections only from localhost, making it quite safe to leave running all the time even if somebody does somehow add NAT entries to forward an internet-facing port to it from their local gateway.
posted by flabdablet at 5:40 PM on February 9, 2012


I would go so far as to write a tiny script to ssh to your computer/server and open a reverse ssh tunnel; you can have them double-click that if something goes wrong with ddns, etc.

The script required is so tiny (one ssh command) that it's easily incorporated in a desktop or panel launcher, and combined with the Vino remote desktop package, makes TeamViewer totally redundant.
posted by flabdablet at 5:47 PM on February 9, 2012


« Older Restaurant Recommendations in ...   |  Is the blog "Margaret and... Newer »
This thread is closed to new comments.


Post