Connecting to multiple computers via SSH behind only only one public IP?

Question

I have the following predicament. I find myself becoming more and more used (albeit paid) as the "computer guy" in the neighborhood for "fixing" common "issues." Being a hacker, I've thought of providing as a service to my clients remote assistance via SSH/VNC. Conceptually, this is great, but there are a few implementation details I'm wrestling with.

1. Determining each customer's router's IP address. This can be done usually with Dynamic DNS, but I've thought of writing a small program which will send the current IP address of the router to my server, so I can keep on top of things. Dynamic DNS is, of course, easier, but it could get complicated if I'm using an external service. I'm a cheapskate, so the less I have to pay, the better, and it wouldn't be ideal to have to set up a new account for each customer's router. Here are my options for Dynamic DNS:

   1. I could pay monthly for hosting for a nameserver, and create a domain hierarchy that makes sense and implement dynamic DNS.
   2. I could buy a low-spec server and host BIND and do everything locally, but as above.
   3. I could charge clients per month (!?!) for "Dynamic DNS hosting fees" and use the proceeds to pay for a nice account from DynDNS.org or something.

2. Supporting multiple computers beyond their router. For this, I also have options:

   1. Implement OpenVPN where possible and simply use the remote VPN to access the computers as I would if they were local machines on the network. (That's how VPNs work right? I would essentially show up to the router as just another IP address and I'd have full access to all machines in the network, correct?)
   2. Implement some reverse connection hack to have them connect to me and then have me establish the SSH connection with them.
   3. The icky, port-forwarding way. This involves keeping a database of each customer and each customer's machine's port number for SSH on the router. Yuck.

3. Being able to support laptops remotely. Say my customer is at a coffee shop in another state and something goes wrong. Since many of the solutions above deal with router-based solutions, everything goes out the window. It doesn't matter too much to be able to do this up front, as it's kind of an edge case, but still.

Can someone recommend the best way to 1. find the public IP address of each machine, 2. establish a connection with it, and 3. possibly provide remote*remote service if they're "roaming?"

Answer 1

Many of the issues can be ignored when using TeamViewer. The client only needs to start the program and report to you the ID (static) and password (temporary); the program takes care of bypassing NATs and offers remote desktop and file transfer. There's no alternative to SSH, but TeamViewer apparently also allows VPNing into the client's network. (I'm not sure if this works without Admin/root.)

For dynamic DNS you can reuse the existing "DynDNS updater" tools, for example, inadyn – they can be pointed to arbitrary servers, and they all work by making a simple HTTP request you can log.

For "supporting multiple computers beyond their router", IPv6 comes to mind – if only your ISP supported that... otherwise, VPN (you're right about how they work) will be more reliable if an internal address changes or a new device is connected.

Answer 2

Have you looked at the web-based services like logmein or gotomypc? I use logmein when I'm helping my dad and I believe they do have a product that might suit your needs.

Answer 3

For VNC from the "client" side (that might be behind firewalls/routers etc) setting up a server at your end with listening is what I think you are looking for. Raymond cc has made a nice and good write-up on how to tdo that: http://www.raymond.cc/blog/archives/2007/04/05/free-and-easy-remote-access-with-vnc-reverse-connections/

For SSH revese connections can be done like "nohup ssh -f -N -R 10000:localhost:22 username@your_side" that will make a ssh to your_side:10000 end up at the client you are trying to support. This will require a username at your end you can give out to your clients of course. More details can be read at for instance http://www.vdomck.org/2005/11/reversing-ssh-connection.html

Both these will require the persons you are trying to support do some "start up" work at there end, but that is usually (in my experience) a big problem.