Secure, remote administration of a Mac OS X computer from within Windows

In a recent post about multimedia file format conversions, ripping DVDs, playback and more, I linked to a number of Mark Pilgrim’s “How To” articles; however there was one which wasn’t relevant to that particular post – how to use your Mac from anywhere (although it is intended for remote control of a Mac the advice should be equally applicable to a Linux system, or even to a Windows Server with an SSH server installed).

A few months back, I blogged about using creating an SSL VPN to access my network but Mark’s video explains how to open a single firewall port and use SSH to provide a secure tunnel through which other protocols (in this case VNC) can be run for remote administration of a single computer. I tried it earlier and it’s very straightforward. Best of all, the software involved is all freely available under open source licensing agreements!

I recommend downloading Mark Pilgrim’s video for a full explanation but the notes below explain what is involved (some of the Unix concepts may be unfamiliar to those more used to a graphical environment and my quick introduction to Linux for Windows administrators might be useful):

1. Download and install the PuTTY, PuTTYgen, Pageant and Plink SSH utilities on a Windows PC.
2. Using puttygen, generate a public/private key pair and protect it with a passphrase. Save the private key to a file on the Windows PC and copy the public key to the remote computer (e.g. within a text file transmitted via e-mail or FTP).
3. On the Mac, open a terminal session (either using the OS X Terminal application or an alternative such as iTerm) and enter the following commands from the home (~) directory:
   • mkdir .ssh (this was already present on my machine as I already had the SSH server running).
   • chmod 700 .ssh (again, I didn’t need to do this).
   • chmod 600 publickeyfilename (the default permission set is 640).
   • mv publickeyfilename .ssh/authorized_keys
   • sudo nano /etc/sshd_config (non-admin users may need to su - to an admin account first as explained in my earlier post about running sudo as a standard user) and make the following edits:
     • Allow SSHtunnelling (also known as TCP forwarding or port forwarding) by changing #AllowTcpForwarding yes to AllowTcpForwarding yes
     • (Optionally) Prevent the use of usernames and passwords for login (the public/private key pair and passphrase will provide the security for the connection) by changing #PasswordAuthentication yes to PasswordAuthentication no
     • (OS X 10.4 only) Disable pluggable authentication modules by changing #UsePAM no to UsePAM no
   • Exit nano and save the changes to /etc/sshd_config (exit to the original shell if su was previously used to escalate privileges).
   • Generate an SSH key fingerprint (to prevent man-in-the-middle attacks) using ssh-keygen -l -f /etc/ssh_host_rsa_key.pub and make a note of the fingerprint.
4. Open TCP port 22 on any firewalls/routers between the Windows and Macintosh computers and enable port forwarding to the appropriate internal IP address (it may be necessary to apply a static IP address to the Mac but I prefer to use a DHCP reservation).
5. If the external IP address for the network is not static (mine is) then use a dynamic DNS service to assign a DNS name so that it may be located on the Internet.
6. Within the OS X System Preferences, Open Sharing and enable Remote Login (restart the service if it is already running in order to pick up the changes made earlier to /etc/sshd_config). Because password authentication has been disabled, remote login (SSH) will only be possible from a machine with the appropriate private key.
7. Although OS X includes Apple Remote Desktop, which is a VNC server, alternatives such as Vine Server (OSXvnc) offer additional functionality. In particular, VNC is insecure by default; however by selecting to only allow local connections (require SSH) and start the system server (i.e. run as a service, rather than in the context of a particular user), it is possible to run a secure VNC server each time the system is restarted.
8. At this stage, it should be possible to create an SSH tunnel to the Mac. On the Windows PC, run pageant which is a PuTTY helper application (SSH agent) to cache the passphrase for the private key, which adds a level of security if the PC is compromised but which would also become a nuisance if it needed to be repetitively entered. Add a key using the private key file generated in step 2 and enter the passphrase that was used when created the key.
9. Next, run putty and enter:
   • The hostname/ipaddress in the basic session options.
   • The auto-login username for the Macintosh for the connection data.
   • The privatekeyfilename for SSH authentication.
   • A new forwarded source port of 5900 and destination of localhost:5900 for SSH port forwarding.
10. Save the session with an appropriate sessionname and open the connection. On the first connection, the host key will be unknown; however the reported key can be compared with the one generated earlier to ensure that the host is the intended target computer. Assuming that all is well and the connection is allowed to continue, then a Welcome to Darwin! greeting should be displayed, along with a shell prompt.
    • If the connection fails and there is a prompt for the private key then Pageant is not correctly configured.
    • If there is a prompt for a password then /etc/sshd_config was not correctly edited.
11. Unless command line interaction with the Mac is required, the PuTTY window can be minimised. In order to create the SSH tunnel automatically at login, a startup shortcut can be created with the target of "%programfiles%\PuTTY\pageant.exe" privatekeyfilename -c "%programfiles%\PuTTY\plink.exe" sessionname
12. Finally, a graphical connection may be initiated with a VNC viewer such as UltraVNC. The connection should be made to localhost; however because localhost:5900 has been defined as the forwarded port in the SSH tunnel, the request is securely transferred to the VNC server on the Mac.

It’s worth noting that when I originally tried to test this configuration from a remote network I was unable to get past my employer’s firewall; however there are plenty of unsecured wireless networks around which I could use to test the connection!

Note that the original information that provided inspiration for writing this post is licensed under a creative commons attribution sharealike 2.5 license and consequently so is the information contained in this post.