As we saw earlier, an encrypted connection between two machines is often referred to as a tunnel. But to be clear, all of the traffic involved is flowing through the same “pipes” as all other Internet traffic. The packets are just TCP packets, and the only significant thing about them is that they are encrypted in some manner.
This is not exactly rocket science, and with a little information you can create one yourself. Some years back I worked for a hospital and one of my responsibilities was to help our business partners (usually large doctors’s practices) get set up with a VPN for secure communication. In the U.S. there is a law called HIPAA that can levy large fines on hospitals if they are careless with patient data, and believe me hospitals take this very seriously. So VPNs were important here. Now, I was not the guy actually modifying the firewall in these cases. I was more of an expediter and customer contact, but I worked with the firewall team. Our hospital had a firewall, and behind the firewall everything was NATed, meaning that none of our machines had Internet Addresses that could be publicly available, or even routed. And frequently the customer had a similar setup. So the process involved getting everyone on a conference call and agreeing on:
- What IP address each party showed to the outside world
- Which port the packets would come to
- Which encryption algorithm would be used
- What key length would be required
and so on. Then on our end we had to write traffic rules that said “If a packet arrives at such-and-such a port, and it obeys these rules, and comes from this particular IP address, send it to this particular server inside the network.
Now, the wonderful thing is that all of this technology is available to you as well, and can provide you with a lot of security. For example, going on the Internet at a coffee shop, or in an airport terminal, can be a security risk. Anyone else on the network could be sniffing your packets and getting your confidential information. And if you were connecting to a corporate network, the downside could be catastrophic. But there is an answer, and that is VPNs. And SSH can create one for you easily.
OpenSSH has an extension to allow the creation of VPNs. This is not as full-featured a solution as a dedicated VPN solution (we will get to that later), but for a simple solution it might be just fine. And the process I went through at the hospital gives you some clues as to how this might work. For instance, I have a small network in my home, and all of my machines are NATed behind a firewall. So if I wanted to create a secure connection to my home network, I would need to put some kind of rules in place on my firewall to pass the traffic through properly. The router would need to pass the packets on, then the question becomes if I have a hardware firewall between the router and my internal network. I won’t get into all the combinations on that, I am just noting in passing that you will need to consider this as well.
TUN/TAP Devices
In networking, TUN and TAP are virtual-network kernel devices. Unlike hardware devices, they exist entirely as software. TUN refers to a network tunnel, simulates a network layer device, and operates with layer 3 packets such as IP packets. TUN is used for routing. If you are unfamiliar with some of this terminology about layers, this is a reference to the 7-layer OSI model, and Wikipedia has a good explanation at https://en.wikipedia.org/wiki/OSI_model. TAP is short for network tap, and means the same thing as tapping a line, only instead of being a hardware tap this is software. TAP simulates a link layer device and operates with layer 2 packets like ethernet frames. TAP is used to create a network bridge.
I mention all of this because in documentation and configuration files you may run into these terms, and it helps to have some idea of what they mean. You can get more information from Wikipedia at https://en.wikipedia.org/wiki/TUN/TAP. and if you want to really dig into this, you can consult the documentation at https://www.kernel.org/doc/Documentation/networking/tuntap.txt. But note that you can work with this without getting that detailed.
An SSH VPN employs a TUN interface, therefore, to create a virtual link between two machines. This creates a point-to-point connection, and the two machines attach themselves to this tunnel interface. If you connect via TAP you have a layer 2 TAP tunnel. Neither of these is overly easy, but the difference is that TUN connection can only handle IP packets in IPv.4. If you want to connect using IPv6, IPX, etc. you really have to be bridging, and that means TAP. For this particular tutorial I am going to assume TUN with IP traffic only. This has some advantages, in that you probably have the software already installed and configured, and you can use your pre-shared keys for authentication. The main disadvantage is that it runs over a single TCP connection, which may be fragile.
If you are interested in more on TUN v. TAP, I would recommend the OpenVPN documentation at https://community.openvpn.net/openvpn/wiki/BridgingAndRouting.
OpenSSH Tunnels in Linux
OpenSSH allows VPNs as an extension to the SSH protocol, and it can be useful for a quick-and-dirty point-to-point connection, but if you want serious VPN construction you should probably look at a protocol OpenVPN. A good page for help on setting this up can be found at the Archlinux wiki at https://wiki.archlinux.org/index.php/VPN_over_SSH. Also there is a good site at The Unix Toolbox.
To start, you need to configure the sshd_conf file with these options:
PermitRootLogin yes
PermitTunnel point-to-point
Now, there are four options for the PermitTunnel line: No, Yes, point-to-point, and ethernet. If you select No, there will be no tunnel, so that would not be a good idea. If you select Yes, you can create any kind of tunnel. Point-to-point creates a layer 3 tunnel between two machines. It needs some configuration for routing, but is usually the best type of tunnel for an SSH VPN. If you select Ethernet, you create a layer 2 connection that allows both locations to share their local LAN. And as Michael Lucas points out “Configuring routing is trivial compared to the difficulties of debugging Ethernet broadcast problems from the other side of the country.”
You will also note that the first line we added allows root login. the reason is that to set up an SSH tunnel you need to be root, and there is not a good way around that. If you change that line to
PermitRootLogin without-password
this will not do what you might first suspect. What it really does is force a login only with key authentication. The root password will not let you in. I will give an example of each.
Then, all SSH tunnels must be initiated from the client side, which is the “local” machine in general. You are logging in to the server when you create a tunnel, so you need to be root on the server to do this. The ssh command has a switch, -w, which creates a tunnel. The tunnel needs to be given a number, which can be anything not already in use. If you are creating the only tunnel used on either server, you could easily use the number 0. So your commend on the client is:
ssh -w0:0 root@hserver
So in order, the command is ssh, the switch -w tells it to open a tunnel, the first 0 is the client tunnel number, the second 0 is the server tunnel number, and finally you are logging in as root on the server. For this to work, you need the root password, and the sshd_conf file needs to read PermitRootLogin Yes.
Then the server will give you a prompt, and you should enter this:
ifconfig tun0 serveripaddress netmask 255.255.255.252
PuTTY and Windows
I will assume the server is Unix-like and just focus on the client here. IF you are running Windows you will probably want to use PuTTY to set up your SSH VPN, and it is not difficult. Open PuTTY, and on the left scroll down to Connection–>SSH–>Tunnels. On the right you need to enter a source port, which can be any port you have rights to use and is not already being forwarded, such as 16180. Then scroll up on the left to Sessions, enter the name or IP address of the remote server, and check the port. Port 22 is the default for SSH, but as we discussed earlier the server may have been set up to use a different port, and if that is the case it here.
That is about it for setting up an SSH VPN Tunnel.
Save as PDF