I decided to put together his how-to after reading the Switching my Granddad thread and figuring there are probably a number of others out there who serve as the de facto tech support person for friends and family in remote locations. The idea is to be able to remotely view and, if needed, control another Mac to help teach a new Mac user how to do something or fix their problem.
This isn't the fastest thing in the world mind you (anything they do with much in the way of graphics, like iPhoto, takes a long time to paint on my end), but it definitely works well enough for what I need. My method certainly isn't the only way of doing it, but it meets my criteria, which are:
[For the purposes of this how-to, the Mini is my dad's computer, and the powerbook is my computer - should help keep things straight as far as which computer needs to do what. I had Apple ship the Mini to me directly so I could set this up in advance, but the same could probably be done remotely without too much pain.]
So, the first thing I did was upgrade his Mac to the latest ARD client software. This is free on the Apple site:
http://www.apple.com/support/downloads/appleremotedesktop21client.html
It's called the ARD client, but in truth it's really a VNC server under the sheets. I had the luxury of being able to do this myself since I had his Mini at the time, but it's really pretty easy and I'm confident I could have talked my dad through the install over the phone.
Once that was installed I went into the Sharing prefrences pane on the Mini and started the ARD service. I also went into the Access Privileges for ARD and enabled "VNC viewers may control screen with Password". Just put any old password in - it doesn't matter and will be ignored since we're tunneling over ssh. I also put a check next to his user account and checked "Observe" and "Control" (not actually sure if this is necessary, but whatever). Note that I did NOT need to open up the ssh ports on the Mini or the Mini's router since the Mini is sending the ssh request outbound (it's a reverse tunnel), not receiving ssh requests inbound. Also I did not need to open up the ARD port (5900) on the Mini's router; however OSX will automatically open ARD ports on the built-in software firewall when you start the ARD service. Technically you can close these ports down on the Apple firewall since the traffic is tunneled over ssh, but that's beyond the scope of this project.
Next I enabled Remote Login (i.e. ssh server) on my Powerbook. I created a dummy, non-priveleged account (called "dummy") to receive the tunnel. I generated a DSA public-private key pair on the Mini under my dad's account (in Terminal, type "ssh-keygen -t dsa" and accept the defaults). I copied my dad's public key to the ~/.ssh/authorized_keys2 file under the dummy account. This step isn't really necessary if you don't mind your switcher having to remember and type in the dummy user's password, but that didn't meet my "simple" criterion above. Again I had the luxury of doing this work directly on the Mini, but with iChat and a little cutting and pasting, it can be done remotely as well. Note there's no real security risk having your switcher email or IM you their public key - that's why it's "public".
Next I installed Chicken of the VNC on my Powerbook (http://sourceforge.net/projects/cotvnc/). I assume any decent Mac VNC client would do, but COTVNC was lightweight, free, and worked out of the box with no changes. I also setup a DDNS name for my Powerbook using http://www.dyndns.org/ (again, free). This allows me to hard-code a name instead of an IP on the Mini since my ISP uses DHCP and the IP might change over time. There are various DDNS clients for Mac - I have no experience with them since my Linksys WRT54G router has DDNS support built-in.
I then created a saved Terminal file on the Mini to launch the reverse tunnel. In Terminal just do a File -> Save As then give the file a name. Click on "Execute this command" and enter the following:
ssh dummy@mypowerbook.ddnsname.whatever -R 5900:127.0.0.1:5900
then check "Execute command in shell" and click save. This creates a reverse (hence the -R) tunnel mapping the VNC client port (5900) on my powerbook to the VNC server port (also 5900) on his Mini. It's a reverse tunnel meaning that although he established the connection from the Mini to the Powerbook, the "flow" or the port mapping actually goes in the opposite direction - from the PB to the Mini. Why all the trouble? This means that my dad didn't have to screw around with opening up any ports on his Mac firewall or do any port re-mapping on his router to allow inbound ssh connections. The tunnel eminates from his box but allows me to go back into his. Now all my dad has to do when he wants to establish the tunnel is double-click on the saved terminal file. Magic!
Now since I too am behind a NAT router and run the Mac firewall, I did have to map the ssh port (22) on my router to my Powerbook, and I did have to open up the ssh port on the Mac Firewall. But I can turn all this off when the tunnel isn't in use for better security (which is easy since it's on my end, not my dad's). And for the truly paranoid you can turn off the ability for password-based ssh authentication (assuming you setup the public-private key pair) so that there's little chance you could be hacked via a password attack.
Almost there! Now all my dad has to do was double-click on that Terminal file to startup the tunnel. Once that is established, I fire up COTVNC, type in "localhost" under the Host: field, leave the display/port set to 0, leave the password field empty, and click Connect. Voila! The Mini's screen appears and I can use my mouse and keyboard to control it. Note that I do NOT need to be logged in as the dummy user. The whole point of the dummy user is to be the end point for the tunnel. Once the tunnel is up, the ports are mapped for the whole machine - any user on the powerbook can take advantage of the tunnel. Also note that with this method I never need to know the IP address of the Mini - again, for the sake of simplicity I didn't want my dad trying to figure out his router's IP address everytime we start the tunnel.
That's about it. Hope others find this useful. Nothing here is really anything new - just cobbled together a bunch of different pieces into a single solution, and I'm sure I'm not the first to do so.
Regards,
Sean
This isn't the fastest thing in the world mind you (anything they do with much in the way of graphics, like iPhoto, takes a long time to paint on my end), but it definitely works well enough for what I need. My method certainly isn't the only way of doing it, but it meets my criteria, which are:
- secure - didn't want to pass anything in the clear over the internet.
- free - I'm sure that Timbuktu and Apple Remote Desktop (ARD) Server are great products, but what can I say, I'm a cheap bastard.
- built-in - I always prefer to use as many standard built-in tools as possible to keep things simple.
- simple - wanted point-and-click simplicity on my dad's end. Didn't want him typing in IP addresses and such.
- zero or at least minimal network changes on Dad's end - didn't want to have him mucking around with his router and end up hosing himself so that he can't get online anymore since I can't fix that sort of thing remotely.
[For the purposes of this how-to, the Mini is my dad's computer, and the powerbook is my computer - should help keep things straight as far as which computer needs to do what. I had Apple ship the Mini to me directly so I could set this up in advance, but the same could probably be done remotely without too much pain.]
So, the first thing I did was upgrade his Mac to the latest ARD client software. This is free on the Apple site:
http://www.apple.com/support/downloads/appleremotedesktop21client.html
It's called the ARD client, but in truth it's really a VNC server under the sheets. I had the luxury of being able to do this myself since I had his Mini at the time, but it's really pretty easy and I'm confident I could have talked my dad through the install over the phone.
Once that was installed I went into the Sharing prefrences pane on the Mini and started the ARD service. I also went into the Access Privileges for ARD and enabled "VNC viewers may control screen with Password". Just put any old password in - it doesn't matter and will be ignored since we're tunneling over ssh. I also put a check next to his user account and checked "Observe" and "Control" (not actually sure if this is necessary, but whatever). Note that I did NOT need to open up the ssh ports on the Mini or the Mini's router since the Mini is sending the ssh request outbound (it's a reverse tunnel), not receiving ssh requests inbound. Also I did not need to open up the ARD port (5900) on the Mini's router; however OSX will automatically open ARD ports on the built-in software firewall when you start the ARD service. Technically you can close these ports down on the Apple firewall since the traffic is tunneled over ssh, but that's beyond the scope of this project.
Next I enabled Remote Login (i.e. ssh server) on my Powerbook. I created a dummy, non-priveleged account (called "dummy") to receive the tunnel. I generated a DSA public-private key pair on the Mini under my dad's account (in Terminal, type "ssh-keygen -t dsa" and accept the defaults). I copied my dad's public key to the ~/.ssh/authorized_keys2 file under the dummy account. This step isn't really necessary if you don't mind your switcher having to remember and type in the dummy user's password, but that didn't meet my "simple" criterion above. Again I had the luxury of doing this work directly on the Mini, but with iChat and a little cutting and pasting, it can be done remotely as well. Note there's no real security risk having your switcher email or IM you their public key - that's why it's "public".
Next I installed Chicken of the VNC on my Powerbook (http://sourceforge.net/projects/cotvnc/). I assume any decent Mac VNC client would do, but COTVNC was lightweight, free, and worked out of the box with no changes. I also setup a DDNS name for my Powerbook using http://www.dyndns.org/ (again, free). This allows me to hard-code a name instead of an IP on the Mini since my ISP uses DHCP and the IP might change over time. There are various DDNS clients for Mac - I have no experience with them since my Linksys WRT54G router has DDNS support built-in.
I then created a saved Terminal file on the Mini to launch the reverse tunnel. In Terminal just do a File -> Save As then give the file a name. Click on "Execute this command" and enter the following:
ssh dummy@mypowerbook.ddnsname.whatever -R 5900:127.0.0.1:5900
then check "Execute command in shell" and click save. This creates a reverse (hence the -R) tunnel mapping the VNC client port (5900) on my powerbook to the VNC server port (also 5900) on his Mini. It's a reverse tunnel meaning that although he established the connection from the Mini to the Powerbook, the "flow" or the port mapping actually goes in the opposite direction - from the PB to the Mini. Why all the trouble? This means that my dad didn't have to screw around with opening up any ports on his Mac firewall or do any port re-mapping on his router to allow inbound ssh connections. The tunnel eminates from his box but allows me to go back into his. Now all my dad has to do when he wants to establish the tunnel is double-click on the saved terminal file. Magic!
Now since I too am behind a NAT router and run the Mac firewall, I did have to map the ssh port (22) on my router to my Powerbook, and I did have to open up the ssh port on the Mac Firewall. But I can turn all this off when the tunnel isn't in use for better security (which is easy since it's on my end, not my dad's). And for the truly paranoid you can turn off the ability for password-based ssh authentication (assuming you setup the public-private key pair) so that there's little chance you could be hacked via a password attack.
Almost there! Now all my dad has to do was double-click on that Terminal file to startup the tunnel. Once that is established, I fire up COTVNC, type in "localhost" under the Host: field, leave the display/port set to 0, leave the password field empty, and click Connect. Voila! The Mini's screen appears and I can use my mouse and keyboard to control it. Note that I do NOT need to be logged in as the dummy user. The whole point of the dummy user is to be the end point for the tunnel. Once the tunnel is up, the ports are mapped for the whole machine - any user on the powerbook can take advantage of the tunnel. Also note that with this method I never need to know the IP address of the Mini - again, for the sake of simplicity I didn't want my dad trying to figure out his router's IP address everytime we start the tunnel.
That's about it. Hope others find this useful. Nothing here is really anything new - just cobbled together a bunch of different pieces into a single solution, and I'm sure I'm not the first to do so.
Regards,
Sean
