SSH VPN

SSH for an encrypted VPN

Snow Leopard to El Capitan (Mac OS X)

File Sharing, Screen Sharing (or Remote Desktop)
(-using an Airport Extreme Base Station, and Bash Terminal commands, among other things)

-with thanks to Bob Harris, who generously and patiently helped me through this the first time, on Apple Discussions.
I note that some of the details of menus and options vary as we progress through operating systems, but I believe that it's clear enough. Ask if anything is unclear.

What

This is to have Internet access to your base computer (home, office, etc.), one name for which is the "server", from another computer at a different location (different room or different continent), the "client". (In my case, the server is an iMac - an "ordinary" desktop computer - and the client is a Mac laptop/notebook computer - which makes sense for me but is not otherwise relevant.)

This access is strongly and securely encrypted, so that no one eavesdropping on a router along the way can decipher your data, and apparently it will often "tunnel" through otherwise difficult outgoing firewalls (from wherever you are with your "client" computer).

There are probably several approaches to this, but the one described here uses an "SSH tunnel" ("SSH" meaning "Secure Shell"), including its optional Public/Private Key feature. No one can reasonably infiltrate your tunnel without both keys, either of which is kept on only one of the two computers, and which are not reverse-decrypt-able in practical terms, and which themselves can be further password-protected for multiple layers of security.

And the wonderful thing about all of this is that it's included in Mac OS X at no extra charge; all you have to do is learn how to do it (which will however require some time)!

Alternatives: there are commercial software programs which will do this for you, but I didn't find them much easier than doing it this way. I have not looked at Apple's own "Remote Desktop" program, which is a bit pricey. I haven't really looked at how iCloud might function in this context. I understand that some or all of this is possible using iChat. Connecting to a non-Mac computer or to earlier versions of Mac OS X may be possible with further knowledge, which however I do not have. And so on; this is just one approach of many.

Usual disclaimers:

Why

  1. File Sharing over a "VPN" ("virtual private network") - Use data files on your server from wherever else in the world you are. This is exactly like using files on another computer on your private network, except that you've securely extended your network over the Internet. Working while leaving your data on your server can be very convenient, in that you don't have to have multiple copies of files, or remember which one is the most recent, or somehow keep them synchronized. (Alternatively, especially for large files, you could copy a file to your client computer, and when done working with it, copy it back to your server; your call.)
  2. Screen Sharing (aka "Remote Desktop") - Control your server remotely, making keyboard and mouse inputs to it, over your network. You see a copy of your server's monitor on your client computer's monitor. Someone watching your server's monitor would see it doing what it would be doing if you were there, even though you could be half-way around the world (or only across the room). You may have:
    • very large files on your server which could be cumbersome to use over the relatively slow Internet, or
    • software not installed on your client computer, for valid reasons.
    With Screen Sharing, the data which you transmit over the network is usually not much more than just a compressed image of your server's monitor display, which may often be substantially less than actually transferring whole files. (Sound is not transmitted, so you won't hear your server's noises - alarms, music - nothing.)
  3. You can do other things, such as make your server into a private Web server, although I have no experience with this.

How?

  1. For illustration purposes only:
    1. Let's give the server a "computer name" of "YourServer", with an "Account" which you wish to access called "ServerAcct".
    2. We'll call the client computer "YourClient", with an account called "ClientAcct".
  2. For many of us, our server's address, its "IP", changes from time to time, under the control of our ISP ("Internet Service Provider"). This makes the server impossible to find over the Internet, so to get around this we need a "dynamic IP address service".
    • I use Dyn (but there are others), which as of April of 2014 started charging a small fee for their "Remote Access" service.
    • At Dyn, create a hostname (I'll use "soulmate" only for purposes of illustration), and follow the instructions, and you'll end up with an address such as "soulmate.dyndns.org".
    • Download their "DNS Updater" program (from your server, not from your client computer), install and run it. I believe that it needs to be running on your server all the time when you're using your SSH connection.
    This means that wherever you are, you can use that address to find your server, even if the server's address (its "IP") changes. (Don't worry - your computer will still be "closed" for all practical purposes to the outside world, presuming that you have a login password and don't go around advertising your "soulmate" name.) The Updater on your server keeps the Dyn server aware of your server's current IP and translates your "soulmate" address into that IP.
  3. To make things more stable, I assign static network IPs to both computers. This is done on the Airport Extreme Base Station.
    • On your computer, open the program called "Airport Utility" and click "Manual Setup".
    • Click the "Internet" icon along the top and the select the "DHCP" tab.
    • Note the "DHCP Beginning Address" and the "DHCP Ending Address" - you'll need this "dynamic address range" in a moment.
    • Click the "+" button near the bottom and choose any description you like for one of the two computers. (Make it something obvious, of course!)
    • I choose "Reserve address by: MAC Address", and I find the MAC address by ...
    • ... opening the program called "System Profiler", clicking on "Network" along the left-side panel, and then choosing, in the top pane, the type of network access I use, for example Ethernet or Airport, and use that MAC number listed with that. It uses a format like this: 10:AB:23:DE:45:F6.
    • Back where we left the Airport Utility, enter that MAC number, and choose an IP address. It will usually be 10.0.1.x, and choose a number for "x" outside the dynamic range of your Airport Extreme Base Station (noted above). Click "Done". Let's similarly call the client computer's address 10.0.1.y. (Doing this for both computers makes things easier for one step coming up.)
    • You may close the System Profiler.
  4. For added security, here is an optional step to reassign your SSH-Login port number, so that hackers going around looking for "standard" ports won't find yours in the usual place, and are unlikely to go looking any further.
    • Still in the Airport Utility, click the "Advanced" icon along the top, and choose the "Port Mapping" tab. I think that generally it will be empty. We're going to click the "+" button near the bottom, and then from "Choose a Service", select "SSH - Remote Login".
    • The bottom field, "Private TCP Port(s):", should say 22. This is apparently the usual port for the SSH Login function. Leave it alone. Change the "Public TCP Ports(s):" to a higher number. Choose something with 5 digits but not over 65535(?) and you'll be well out of the range of usually-used, pre-assigned ports. (Don't worry what "ports" are ...). So, as an example only, let's say that you'll use "12345". (Don't use that!) Keep a record of this number in some secure place.
    • For "Private IP Address:", use the IP we assigned to the server just a moment ago, e.g. "10.0.1.x". Click Continue. Choose a name for the Service under "Description" (make it obvious - I use "Remote Login - SSH"). (It seems that the "Service Name" remains blank unless we're using "Bonjour", which we're not.)
    • You may close Airport Utility.
  5. We're going to set certain settings in System Preferences, under Sharing.
    • On your server, make sure that you turn on "Remote Login", "File Sharing", and "Screen Sharing". (And leave them on forever - or at least when you're going to be away, if you can organize that.)
    • Similarly, on your client computer, make sure that "File Sharing" and "Remote Login" are turned on. You'll be able to turn "Remote Login" off later.
  6. Now we're going to generate our "keys" - the things which give us encrypted security.
    • On the "client" computer, open a program called "Terminal". This provides a "command line" interface which can do many things not possible otherwise. The "command prompt" will look something like:
      	YourClient:~ ClientAcct$ 
      You're going to type (or safer would be to copy and paste) this command, then press the Enter key:
      	ssh-keygen -t rsa
      You will be asked for a password, so as usual it should be a strong password, and something which you can remember. (Again, by using a password here, you foil someone even if they somehow stole both of your keys.) You will then see a "key fingerprint" and "randomart" which I store somewhere secure (in an encrypted text file), but I'm not sure that I will ever need them.
      This command also creates a new folder in your home folder (which is "ClientAcct") called ".ssh" (the period starting a file or folder name means that it's invisible, or "hidden" to use Mac OS X terminology, so you can't see them in Finder), with two files inside it, id_rsa and id_rsa.pub. These are the private and "pub"-lic keys.
    • You can check this at the Terminal command prompt by looking inside the .ssh folder for files, and the command line for that could look like this:
      	ls .ssh
  7. scp ("Secure Copy") command

    N.B. I have trouble getting the "scp" command to work consistently. Recently I first connected the two computers, just on the same private network, using Finder, so that ClientAcct shows up on ServerAcct and vice versa, and then the "scp" command worked. There are several ways to do this connection, and most readers of this page will already know how: "File Sharing" is already enabled (above). Find "Network" or "Shared" in Finder and go from there. You'll need to know the name and passwords for what we're calling here "ClientAcct" and "ServerAcct". Terminal's "scp" command (from ClientAcct) will also then ask you for the ServerAcct password - not your "SSH key" password" - in order to perform its function. "ssh" will ask for the same type of information, in the next step.

    Now, the private key stays on the client computer, but we've got to move the public key to the server. The command line for that will look like this:
    	scp .ssh/id_rsa.pub ServerAcct@10.0.1.x:id_rsa.pub
    (You will of course throughout the following instructions substitute your own names and numbers for "ServerAcct", "x", "ClientAcct", "y", "soulmate.dyndns.org", etc.) This command copies the public file to the server's account's "Home" folder (i.e. "ServerAcct"), plainly visible (temporarily). On the server, you'll be able to see it in Finder. At this point or later, if you're sure that the file transfer worked, delete the public key from the client computer. The command will be:
    	rm .ssh/id_rsa.pub
    Check it again as above with the "ls .ssh" command - it should be gone. It's important to delete it or someone stealing your laptop could figure out how to access your home computer (although the key itself is also password-protected).
  8. Switch to working on the server. Open Terminal. The command prompt, using our illustration-names, will be:
    	YourServer:~ ServerAcct$ 
    The first command will look like this:
    	ssh ClientAcct@10.0.1.y
    This creates a hidden folder (.ssh) on the server (like the one we made earlier on the client computer), inside your home folder (ServerAcct). (At this point, Terminal, despite that we're still working on the server, switches to a prompt indicating that it's working on the client. I just close the Terminal window and open a new one to get back to the server prompt.) Now, still on the server, we are going to insert or add the public key into a file called "authorized_keys", which will be created or appended to, and which resides inside the .ssh folder.
    	cat $HOME/id_rsa.pub >>$HOME/.ssh/authorized_keys
    Be very careful about the exact command, without altering the spacing, etc. It can be copied and pasted from here into Terminal. Then, if you wish to be really compulsive, you can check this process by looking at the key itself and then at the authorized_keys file and see if they look the same, or at least if authorized_keys contains the same character sequence.
    	cat id_rsa.pub
    	cat .ssh/authorized_keys
  9. Delete the file on the server, id_rsa.pub. You can do this from Finder (or from Terminal, using "rm id_rsa.pub", which does not put it in the Trash, but deletes it immediately). Empty the Trash; you need to make that public key as hard to find as possible. The only copy of it now resides inside the "authorized_keys" file, inside the hidden folder ".ssh".
  10. We're close to being able to use our encrypted SSH tunnel.
    • Make sure that the server won't go to sleep or that if it does it can be awakened by "network access" (System Preferences -> Energy Saver). This used to work only with Ethernet access, but now it just says "network access" and does indeed seem to work with WiFi too. Have the Dyn Updater running properly.
  11. Here we go.
    • From the client computer - and you can test this even if you're at your home or office, on the same private network with your server (although then make sure that each computer has "ejected" the others "account" so that you're sure that it's going to be the SSH tunnel which you're tesing) - open the Terminal program. Presuming that both computers have network connections of some kind, including Internet connections, type a command like this (substituting your own data, of course):
      	ssh -p 12345 -L 23456:localhost:548 -L 34567:localhost:5900 ServerAcct@soulmate.dyndns.org
      When you do this, you will be asked on occasion for your key's password. You will occasionally get notices about "authorized keys" and such, but they don't seem to disturb the process.
      You'll notice the "12345" from resetting the SSH Login port in the Airport Utility earlier. The SSH "request" comes in from the client computer on that port number, and is then sent from the Airport Extreme Base Station to the server with the standard number. (Don't worry; it just works.) With the other numbers, "23456" and "34567" (examples only - use other "random" numbers when you do this yourself!), you're doing something similar for the standard ports for File Sharing and Screen Sharing, for added security.
    • And we get at those ports like this:
      From the client computer, when the active menu is "Finder", type "Command-K" to get the "Connect to Server" function (or get it from the Go menu).
    • For File sharing, enter
      	afp://localhost:23456
      substituting whatever you chose for your port number. (Thereafter, "Connect to Server" remembers your command and you reuse it without typing.) For Screen Sharing, type
      	vnc://localhost:34567
      again substituting your own number.
      You'll be asked each time for your server's home folder's password.

We're (almost) done!

And that's it! Your encrypted SSH tunnel is up and functioning, and you can use File Sharing and Screen Sharing immediately.

It won't be as nearly fast over the Internet as on a private network, but it will work.

Sometimes, however, my tunnel collapses and I have to restart it. Rarely, it just doesn't work, and then two hours later, it may suddenly cooperate. If the server locks up, you're out of luck. I have mine to set to power back on automatically after a power failure (cool!).

Screen Sharing is faster if you "Turn Scaling On" (View menu) and also use "Adaptive" video resolution. You can copy and paste back and forth between the server and client computer from the Screen Sharing Edit menu, or from buttons in the Screen Sharing Toolbar.

Things which you will need to remember:
  1. your key's password;
  2. Your SSH "Public TCP Port" number ("12345" in this example);
  3. the internal network address of your server ("10.0.1.x" in this example);
  4. the port you've chosen for File Sharing ("23456" in this example), the port you've chosen for Screen Sharing ("34567" in this example), and ports for other functions which you may use such as "Web server";
  5. your "Account" name on your server ("ServerAcct" in this example) and its password (the same one you use for a usual, local login);
  6. your Dyn (or other similar) address ("soulmate.dyndns.org" in this example);
  7. ensure that your server won't "sleep" or that it awakes properly from sleep;
  8. leave the DNS Updater (or equivalent) running on the server.

(I remember all of the numbers by keeping them in a password-protected virtual disk on my computer[s], but that's another story.)

Prevent Tunnel Collapse

This didn't seem to happen as often a year or three ago as it does now, that the tunnel collapses, with the message: "Write failed: Broken pipe". Sometimes that's because the server times out after some undetermined period of inactivity. There are several places around the Web which discuss options to tame this behaviour, but the best option for me seemed to be to place a file called "config" (with very restrictive permissions) inside the .ssh folder on the client. That file on my client computer contains exactly this:

	Host * 
	 ServerAliveInterval 300

Apparently, indenting the second line matters(?!). Anyway, this sends a tiny confirmation (i.e. low overhead) every 300 seconds to the server, more or less saying, "I'm still here. Stay awake!" You'll need to know how to use the move ("mv") or copy ("cp") command if you use TextEdit to make the file, and how to do the addressing. For example, from your client account "Home" folder, presuming that you've created "config" there:

	mv config .ssh/config

The restrictive permissions could be like this:

	cd ~/.ssh
	chmod -N config
	chmod 600 config
	ls -lea
	cd ..

These five commands i) change to the .ssh folder, ii) remove "ACL permissions" (if any), iii) limit use of the config file to the owner only, iv) show the permissions of all the files in the folder, and v) change back to the "Home" folder. The listing for the config file on my computer looks like this:

	-rw-------@  1 ClientAcct  staff    32 10 Feb 21:22 config

Addendum

A few things have come up, as of 2015 February, so here they are:

Conclusion

So, having written it down, no wonder it took a while the first time. There's a lot to it.

Enjoy! Questions, comments and suggestions always welcome, but remember that this isn't my "area".

ctLow

Valid XHTML 1.0 Strict

© 2011-2016 ctLow - SSH VPN on Mac OS X - 2011-01-05 -updated 2016-09-11