JUST RELEASED: Visit the Incredible PBX WikiToday we’re going to tackle all the flavors of Remote Access for your Mac. It’s a must-have resource for Road Warriors and anyone using their Mac as a server of almost any kind. There are dozens of great remote access tools available but, in the interest of not putting everyone to sleep at once, we’ll focus on some of the built-in (i.e. free) tools, the best of the open source tools (i.e. free), and a couple of the more popular commercial products. The prerequisites for all of these tools are having an always-on Internet connection and having an always-on Mac. And sleep mode doesn’t qualify as ON insofar as remote access is concerned.
There are two types of remote access tools in my book: safe and dangerous. Safe in this context means the connection between you (wherever you are) and your Mac server is always encrypted so that others can’t intercept your password or data. Dangerous means everything else such as FTP. We’re only going to discuss safe remote access tools, and I’d urge you to think twice about enabling or using anything else. Once someone intercepts your unencrypted password, they basically own your Mac and all the data that’s stored on it. So ask yourself if that’s a risk you are willing to take. And I think you’ll probably come to the same conclusion we have: Just Say No.
If you’ve been following our advice, then there is a hardware-based firewall of some variety between your Mac server and the Internet. And your Mac has its built-in firewall enabled as well. Before remote access will work, you’ll need to open the SSH (secure shell) port (22) by accessing the Sharing Folder under System Preferences. Just check the Remote Login box to enable other computers to access your Mac using SSH. You’ll also need to create a rule in your hardware-based firewall that passes Port 22 traffic to the IP address of your Mac. If you don’t know what your Mac’s Internet address is, just click here using a web browser on the Mac in question.
Once you have enabled Remote Login, your Mac automatically starts three UNIX servers: SSH for remotely logging in to your machine, SCP for remotely copying files to/from your machine, and SFTP which is functionally identical to a traditional FTP server except the connection is secure. With SSH, the simplest way to access your server from another machine is to open a Terminal window, switch to root access (sudo su), and then open an SSH session: ssh 111.111.111.111 where the IP address is the actual IP address of your server. If you’re inside the hardware firewall with your server, then you can use your internal IP address as well. Unless you’ve installed a security certificate on your Mac (which really isn’t necessary since an unregistered one will be generated automatically), you will be warned that the authenticity of your server cannot be established. Just type yes to proceed, and then enter your root password. Once you’re connected to your server, you can do anything you could do from a Terminal window sitting at your machine. Type man scp for a tutorial on how to use the secure copy program. q gets you out. When you are finished with your SSH session, type exit to logout.
Secure FTP works similarly. You login by typing: sftp username@111.111.111.111 where username is an actual account on your server and the IP address is your server’s actual IP address. After typing your password, you will be presented with the sftp> prompt. Type ? to see the list of possible commands. When you are finished with your SFTP session, type exit to logout. If you only need to copy files back and forth to your Mac server, this is probably the easiest and simplest method to use. And it’s free.
If your primary remote access requirement is to copy files between your Mac and a remote machine but you prefer the ease of use of a Mac OS X Aqua interface, then there is no finer program than Transmit (see inset). While it’s not free, $30 won’t break the bank for most folks, and you’ll be getting the top of the line FTP and SFTP product available in the Mac marketplace. If, down the road, you decide to use a web hosting facility for your web site(s), Transmit is the one tool you simply cannot live without. Copying files is as simple as dragging and dropping them into a Transmit window. If you can’t tell, we use Transmit ourselves for managing web sites and have for many years. You won’t be disappointed.
There’s another type of Remote Access program. The applications in this group are designed to let you remotely display and control the desktop of your Mac. In other words, what you see is the same thing someone sitting in front of your Mac server would see … only slower. For some, this is an essential component of remote access. For others, it’s a big waste of computing and bandwidth resources. Just be forewarned that Remote Control software is not perfect and is resource intensive, and you won’t be disappointed if you have a fast broadband connection in both directions on both machines. Keep in mind that a typical Mac display these days exceeds 700,000 pixels with millions of colors, and it will give you some idea of the amount of data which must be transmitted just to replicate a single static screen. And that’s before you ever move your mouse! Yes, there are compression techniques and shortcuts that the various applications use to reduce the size of the screen transmissions, but it still is a bandwidth intensive operation because of the screen sizes and resolutions of today’s monitors. Apple makes a perfectly acceptable commercial application to handle remote control called Apple Remote Desktop 2. And, if money is no object or for large organizations, it is a perfectly acceptable solution for remote control. You should be aware, however, that half of the Apple remote control package is available at no cost to users of Mac OS X v10.3. That half is now standards-based and, because it’s free, we’re going to take advantage of it today. Standards-based means that it is compatible with every VNC client for virtually every computing platform in the world, all the way down to cellphones and PDAs if you can stand the performance. The other half (purchased from Apple) will set you back $299 for 10 clients or $499 for unlimited clients. The good news is you don’t need the costly half because there is a standards-based product for Macs which works well and is only getting better. Finally, be aware that this remote control solution is not encrypted meaning that it is possible (theoretically at least) for someone at your ISP’s router to intercept the data. With built-in compression, the data stream still would pretty much be gibberish, but at least it is something you should be aware of. See the comments to this article for an approach that uses an SSH tunnel.
So our remote control approach will be to download and install the latest version of the Apple VNC client. And then we’ll download the standards-based Chicken of the VNC to handle access to the remote desktop. And, as we mentioned, any standard VNC product can be used to connect to the Apple VNC desktop once we get it upgraded to version 2.1. You can read all about the history of Bell Labs VNC software and all of its supported platforms here. Finally, a word about nomenclature. The piece of software residing on the host machine always has been called the VNC Server until Apple came along and named theirs the Remote Desktop Client. The piece of software on the traveling machine that is used to connect back to your host or home base has always been called the VNC Client except Apple calls theirs the Apple Remote Desktop. Sounds confusing? You bet. For our purposes, we’ll refer to the Host Machine (meaning your home base host) and the Remote Machine (meaning the computer from which you are making the connection to your host machine). Whew!
Now, let’s upgrade the software on your Host Machine to make sure the standards-based remote access products will work. Just download and install the Apple Remote Desktop Client 2.1 from here. When you complete the installation, you will need to enable Apple Remote Desktop under the Services tab in the Sharing folder of System Preferences. Then click on the Access Privileges button, choose a user account, make sure all the boxes in the right column are checked, and check the "VNC viewers may control screen with password" option. Enter a password that you will use for remote access. Leave the "guests may request access" option unchecked, or you’ll have to have someone sitting at your host machine to grant access. Click the OK button to save your changes. Next, you need to open the firewall ports on your Mac and your hardware-based firewall to support remote access. Click on the Firewall tab. Then click the New button. Choose VNC (5900-5902) from the pull-down list. If it will only be you connecting to your host machine, then you only need to open port 5900 on your hardware-based firewall and point it to the internal IP address of your host machine. That completes the Host machine installation and setup for remote control.
Now let’s do the other half: the traveling or remote machine software, aka the VNC client. To test this, you’re going to need a second computer (not necessarily a Mac). It’s helpful to have a second computer inside your hardware-based firewall so we can get the kinks out before you try this on the road. If your second machine is also a Mac, then the software you need is Chicken of the VNC (get it?). Download the 2.0b2 version from a SourceForge mirror site to your Desktop. Once it is installed on your Desktop, drag the icon to your Applications folder. Double-click on the icon to start the application. The VNC Login screen will appear. Fill in the IP address of your Host machine and the password you assigned when we enabled the Apple Remote Desktop. The Shared Display checkbox lets more than one person connect to the same Host at the same time so long as you use different ports. Port 0 uses 5900, port 1 uses 5901, etc. The ports have to be open and pointed to your host on your hardware-based firewall. For now, you can leave Shared Display unchecked and make sure the Port is set to 0. Leave the Default Profile setting as is and decide whether you want to save your password in your keychain. That’s all there is to it. Click the Connect button and the screen of your Host machine should miraculously appear. You can toggle the Host machine display between a window and full-screen by pressing Command-Option-Control-`. To disconnect, just close the Host machine display window or choose Connection, Close Window from the title bar menus.
For additional assistance and terrific web-based documentation, just click on Help while the program is running. To keep up with the latest developments of Chicken of the VNC, visit MacUpdate. If you need VNC software for other platforms, Real VNC has the latest versions and AT&T’s VNC archive is another worthwhile site although it now is over five years old. VNC clients also are available for Palm devices and Treo smartphones as well as Pocket PCs and compatible smartphones. Enjoy!
What about VPNs?
[WM: The focus of today’s article was remote access tools to let you connect to your Mac from afar and use it or manage it. The tools identified are more suitable for this purpose. There is a place for VPNs, but this wasn’t it. I’m also a firm believer that VPN servers should be handled by separate hardware because of the computational resources required. There are perfectly good VPN solutions included in some home/small business firewalls such the offerings from Netgear. Even VPN clients, however, get complicated in a hurry, and we felt that topic deserved separate treatment … but we will get to it. Thx.]
Read your nice little writeup on Remote Control of a mac mini.
I couldn’t help but notice that you are recommending that people use the ARD 2.1 client for the VNC Server.
As the maintainer of OSXvnc I was curious if you were aware of our free vnc server for OSX but chose to recommend ARD instead.
I’m hopeful of the day when ARD becomes a great VNC server, but IMHO totally unbiased of course – they aren’t quite there yet. OSXvnc works on 10.1 and 10.2 not that many Mini’s will be running that . OSXvnc also supports pasteboard access which the ARD server client lacks. And we dodge the whole nomenclature problem by calling our server a server not a client.
Anyhow if you weren’t aware of it you should checkout http://www.redstonesoftware.com/vnc/
If you were, I would be happy to hear about the reasons for your preferences for ARD.
Thanks for listening,
Jonathan Gillaspie
[WM: I was aware of OSXvnc and liked it very much. In fact, I had intended to include it until the article kept getting longer, and longer, and longer. There was nothing at all wrong with OSXvnc, but my primary focus was the Mac mini with its included OS X 10.3, and Apple’s server (aka ARD 2.1 client) just happened to be part of that bundle. So, the bottom line is that there are two great VNC server solutions: one from Apple (which they call a client) and another from Redstone Software (which you call a server). Both work great, and I made a choice based upon nothing more than editorial space constraints. Thanks for writing.]
If you are going to be security conscious why are you letting VNC through your hardware firewall? You already have a secure hole opened for ssh. Why not take advantage of that and forward the VNC traffic over ssh? Being lazy and not wanting to screw with the bizarre command line arguments I use an excellent little utility SSHTunnelManager. You can use it to set up your tunnels on both ends of the connection. I forward traffic from my Mac at home using M$ Remote Desktop Connection via SSHTunnelManager to my Mac server at work and from there it is forwarded to different WinBlows boxes. Nice, safe, and secure. And if you are using WinBlows boxes you can do the same thing with Putty.
[WM: Your approach is a good one. VNC is secure only in passing your password. For more on the process, see the next comment.]
I’m curious about your [since retracted] statement that "VNC is a secure, encrypted protocol." The VNC web site itself says that it isn’t:
"Once you are connected, however, traffic between the viewer and the server is unencrypted, and could be snooped by someone with access to the intervening network."
http://www.uk.research.att.com/archive/vnc/sshvnc.html
Which is it?
[WM: You are correct. Too much time alternating between pcAnyWhere and VNC. 50 lashes to me! Boy, that crow tastes good!]
Why on earth do you advocate to switch to root to open a ssh session? That is really not neccesary. Also ssh 111.111.111.111 should be ssh username@111.111.111.111
[WM: Our subject matter has been managing your Mac as a server so root access is usually necessary. As for syntax, yours obviously works but, like everything else in Unix, there are multiple ways to do just about everything. I used your recommended syntax in explaining scp to show another approach, but feel free to use whatever syntax you’re most comfortable with.]
I know you refer to some folks using an SSH tunnel as a possibility, but, really, this ought to be the defacto procedure, it really ought to be required. FUGU is easy enough to use for tunneling SSH.
Keep up the great writing.
Peace. Love. FreeBSD.
Jason