If you see a lot of banner ads on certain websites, you know that without a Virtual Private Network (VPN), hackers will quickly ravage your computer and burn down your house. Well, that seems to be what they imply. In reality, though, there are two main reasons you might want a VPN connection. You can pay for a service, of course, but if you have ssh access to a computer somewhere on the public Internet, you can set up your own VPN service for no additional cost.

The basic idea is that you connect to a remote computer on another network and it makes it look like all your network traffic is local to that network. The first case for this is to sidestep or enhance security. For example, you might want to print to a network printer without exposing that printer to the public Internet. While you are at the coffee shop you can VPN to your network and print just like you were a meter away from the printer at your desk. Your traffic on the shop’s WiFi will also be encrypted.

The second reason is to hide your location from snooping. For example, if you like watching the BBC videos but you live in Ecuador, you might want to VPN to a network in the UK so the videos are not blocked. If your local authorities monitor and censor your Internet, you might also want your traffic coming from somewhere else.

Using SSH for VPN will work for both cases, although if you are mostly interested in the first case, you are probably going to be happier using a dedicated router or a small computer like a Raspberry Pi dedicated to the task. However, if you are leasing a server somewhere, that option isn’t going to work for you.


You really only need root access to both machines and SSH server on the remote machine along with the SSH client. There is some configuration required on both sides. I use KDE so I used NetworkManager to set things up, although that isn’t necessary. It just makes things easier.

The server needs a few special items set up, but those items may already be present. In /etc/ssh/sshd_config you will want PermitTunnel=yes and you may need to set AllowTCPForwarding to yes, as well.  The firewall may need some tweaks, too. The setup instructions for the NetworkManager plug-in will be useful even if you don’t want to use it.

Client Side

If you are using NetworkManager, you’ll need the plug-in. For Neon and other Debian-type distributions, you can find the network-manager-ssh package and that’s all you need. If you don’t want to use it, you can use this line from the plug-in author’s blog:

ssh -f -v -o Tunnel=point-to-point -o ServerAliveInterval=10 -o TCPKeepAlive=yes -w 100:100 root@YOUR_SSH_SERVER 
'/sbin/ifconfig tun100 netmask pointopoint' && 
/sbin/ifconfig tun100 netmask pointopoint

You will need to be root on both ends because you are creating a tunnel device. This leads to a few problems, even if you use the plug-in. Obviously, you aren’t going to want SSH bugging you for passwords and host key verifications, but if you establish the VPN manually, you could deal with that.


However, most modern systems don’t allow root login with a password, or even at all. So you’ll need to fix that first. In addition, when the NetworkManager runs SSH, it will be looking for host keys and such as root, not as your user. If it can’t find things, it will just die. So you’ll need to make sure that root can log in with no intervention.

To allow root logins to the server, you need to edit /etc/ssh/sshd_config and change PermitRootLogin to yes. I suggest you do this only long enough to do the next few steps. You’ll need to restart the sshd server which means something like:

systemctl restart sshd


/etc/init.d/ssh restart

Then, logged in as your normal user on your local machine, use ssh-copy-id to install your certificate to the host computer. As soon as that works, you should go back and change /etc/ssh/sshd_config to use “PermitRootLogin prohibit-password.” That way you can log in as root with a certificate, but not with a password.

If you’ve logged on from your root account once, SSH probably asked you if you want to accept the server key. If not, that’s going to be a problem. If you can, log in and answer yes so it quits asking. However, if you can’t, we can also turn off StrictHostKeyChecking.

In theory, you can pass extra ssh options to the NetworkManager plugin, but for some reason that doesn’t work on the version from the repositories. If you are starting manually, of course, you can add what you want. However, it is also possible to set root’s SSH configuration in /root/.ssh/configor the global configuration at /etc/ssh/ssh_config.

If you do change the global, consider using /etc/ssh/ssh_config.d if your system supports it. That lets you put snippets in for a particular host that won’t get written over on system upgrades. For example, you might make a file in that directory named hackaday.conf:

Host *.hackaday.com hackaday.com
StrictHostKeyChecking no
Tunnel yes

Again, if you object to the host key checking, then just log in from your root account once and manually accept the remote key. Or, if you are brave, manually edit /root/.ssh/known_hosts.


That should do it. If you are using the NetworkManager plug in, just make a new connection. From there, pick the VPN connections section and select SSH.

You’ll have to put in a few parameters, including the certificate you want to use to log in to the remote machine:

Once you save the connection, you can activate it like you would any other network interface. If you want to see if it works, ask a website for your IP address. Then activate the VPN and do it again. If you have trouble getting the VPN to connect, you can look in the system log to find out what errors SSH is throwing.

Of Course…

There are other VPN solutions. However, since it is almost a sure bet that your remote computer has an SSH server on it, this is very simple to set up with very little planning.

You can do a lot with SSH if you know the tricks. We especially like using it to mount files.

Source link