In the IT world lately there’s been a lot of buzz about VPN, and how to effectively use it for remote administration. During this time, it seems a lot of people are forgetting the roots of remote administration (at least within the last few years), when VPN was just starting to get recognized really. While both do have their pros and cons, which one is better for the administration? Let’s go a little in-depth with both and see.
Hands down, in the general scheme of things, I would say VPN has this area won. While SSH does in fact have a high security standard, the way VPN handles encryption is more intelligent. This is pretty much all because of VPN’s encapsulation method (which will be covered again later) that adds an additional security measure that SSH doesn’t.
For those who aren’t familiar with encapsulation, especially with VPN, here’s a general overview. When you connect through a VPN tunnel, the TCP/IP packets have more overhead. This is due in part to the VPN service placing an encryption header on top of the packet itself. While this does slow down traffic (which will be covered later as well), companies have gotten wise to this technology and added measures to make sure this cannot be tampered with. This is generally done with a token (such as a 6-digit RSA SecurID) which authenticates the user, instead of using (just) a username and password.
In the realm of SSH, the protocol it uses is pretty intensive when it comes to security. The fundamental flaw to this, though, is when a key isn’t used. In previous articles I gave a step-by-step guide on how to set this up, and there’s a major reason for this. When you log in via SSH without using a key, your log in information is sent via plain text. Now, if you’re only connecting to a home computer that’s setting right next to you, it’s almost never an issue. But, say you’re at work and you want to check the iostats on the server, sending your data via plain text would not be the logical choice. That’s basically telling everyone to log into your server. VPN doesn’t have this issue, as the encapsulation header doesn’t contain anything damaging to the user itself, as all the data is inside the packet underneath the encapsulation header.
This is the one that gets to me the most here. For anyone that’s used both protocols, I’m sure they will agree that SSH is the faster of the two. Fortunately, the reason is simple.
In the last point, I talked about how VPN has that encapsulation header to provide an additional layer of security. While it adds that extra sense, it comes at a great price. With VPN, what happens is (not necessarily like this but the basic idea is there), the packet payload is segregated (as a TCP/IP packet length can only be 1500 bytes). This means that less data reaches the destination, requiring more packets to be sent, increasing bandwidth. Once the encapsulation header has been added to the packet, and reaches the destination, the destination then has to remove the header to get the payload from the packet. So, basically, a website that generally takes about 5 seconds to load (for example), can take 10-15 seconds (if you’re lucky).
SSH, however, plays nicely with the data. With or without a key, packets don’t take as long to get from A to B. There is no overhead (i.e.: extra headers) to deal with when it comes to SSH, and while there is a slight speed performance hit, even when using SSH as a proxy that same page can take only 2 seconds longer to load.
Ease of Use
For the administrator setting up the service, this sort of depends. Since most Linux flavors have at least 1 VPN solution in their repos, and I have yet to run into one that doesn’t have an SSH server/client in them, it’s pretty easy for the administrator to just run a single command to install it all. This category, though, is really intended for the users the administrator will have to support with said software.
When I worked on the Ford help desk, I got a lot of calls every day asking for help on how to get VPN to work. While the calls were easy, there was never an easy “click here to solve it all” button we could push. Granted, most of the time it dealt with either a transport/tunneling issue, or sometimes even a port issue, there was a lot more calls than we should’ve received from it. Then there was also the problem of the previously-mentioned SecurIDs desynching. Again, a very easy fix, but it seemed if it wasn’t one thing it was another. I can’t fault the user though, completely, as the e-mail documentation (read: a couple of paragraphs) didn’t go into any detail what-so-ever to assist the user.
SSH, while I never really dealt with it in the same manner as VPN, is a lot easier to use. The thing is, using a key makes the task even easier. Unfortunately there’s not a lot to really say here, as it also depends on how you use SSH (i.e.: PuTTy, OpenSSH client, another SSH client, etc…), but it all pretty much amounts to the same result. It’s all relatively easy to set up, and the administrator can simply pass out a config file (like a script file for Linux) to make the task even easier if it uses a generic key.
Every server is different, which makes this category a bit hard to judge. However, in general SSH is easier to manage, especially when you have a big network. The reason why I say this is because, at least OpenSSH, uses one, maybe two configuration files you have to modify generally. Probably the hardest task is setting it up to use keys instead of password authentication. VPN does make this task easier, though, by offering an online configuration (at least OpenVPN does). Which in the end does make configuration even easier, while you only have to worry about the network configuration (i.e.: making sure VPN access from outside is possible).
When it comes down to it, I personally prefer SSH. VPN would be great if I was running a medium or large network, and/or was super paranoid. However, SSH with key-authentication satisfies my necessities just fine. Basically, if you’re using VPN, know that it might (probably will) need extra configuration compared to it’s sibling, but adds a hefty amount of extra security SSH doesn’t (at a price). If you prefer, you could also set up both, and use VPN when it’s not time-critical, while SSH is used for those moments where you’re against the clock.