Slashdot Mirror
SSH or IPSec?
shawngiese asks: "I'm looking for some feedback on which is the better way to make VPN connections - using SSHv2 or IPSec. My company apliware.com makes embedded linux firewalls here in Switzerland. Our next firmware will be coming out with SSH added to IPSec but during my tests I have noticed that the throughput of SSH is much faster when using the same ciphers. Is there any opinions on which has the better key exchange and also if the performance is better for SSH everywhere or just on our port/CPU? I assume since they both use the same ciphers that the data is as secure in one or the other. Of course IPSec offers full tunneling and encapsulation of more than just TCP but I can SSH through almost any NAT box and with the gain in throughput and many free clients for road warriors (even my Palm Pilot for terminal access) I wonder if SSH might not be the easier VPN than IPSec."
Given the proliferation of NAT on many fronts now, I personally have used, installed and maintained SSH VPNs on many of my clients networks because I find it a lot more reliable than IPSec.
Here in NZ, ADSL is running via PPPoATM and all network terminators must be running NAT (this is a requiremet of the Telco, not of the technology). Because of the much lower costs of DSL vs Frame, this is becoming the default setup for most companies now. IPSec in this kind of environment where NAT is at both ends, or even just one, becomes a real PITA to get running and keep running. SSH just works.
Once the keys are set at both ends, the tunnels just do their thing. Establishing ports is not difficult. For my setup I create Virtual IPs at both ends of the network and then essentially do port forwarding across the tunnel to those ports. Essentially a combination of SSH and (in my case) IPTABLES. Works very well, very sweetly and NAT doesn't cause me any problems.
ipsec has the advantages of encrypting entire lines with a good setup. ipsec has the disadvantage of having to be setup (exchanging keys, etc etc). you do excahnge keys via non-network like a good boy, right?
ssh has the advantage of having very little setup and is uber portable. problem is, you can't encrypt an entire line easily, like you might with stunnel, or the contender, ipsec.
But why contend? You are comparing two things that don't really compete directly. They come about it from different directions. One achieves security by encrypting telnet (and adding a bunch of features), while the other achieves security by encrypting the entire line.
Granted, using both might be overkill, but hey, it depends on how ipsec is used with the OS and when the decripted data is viewable. Anyone get tcpdump to work on the ipsec layer yet?
-
ping -f 255.255.255.255 # if only
I've written up step-by-step instructions and scripts that will do the whole durned thing, no brain required, that are in Building Linux VPNs, but was unable to convince NewRiders that one of these chapters should be the one put online. (Instead they picked chapter 1 which, while fine, doesn't provide any instantly-usable information for someone trying to actually build a VPN.
There are a few examples on stunnel.org for setting one up with Stunnel (3.x). You may also want to learn how to correctly use and restrict passwordelss SSH ability here including using authprogs to restrict commands. (You do use command="",no-port-forwarding,no-x11-forwarding,no -agent-forwarding,from="" in all your .ssh/authorized_keys don't you? )
Eventually, the TCP over TCP factor will kick in, and your VPN will be slow. But with a simple ping timer, you can kill/restart connections pretty painlessly via cron.
Plus, no kernel recompilation is required.
Over stable links, you're unlikely to have a problem though.
I use ipsec and wep on my wireless. wep is the 'tease'.. and ipsec does the work. This is because I want to secure the entirety of traffic...
I can do ssh over ipsec as you mentioned. I never really noticed a speed slowdown, but never benchmarked it.
If there is only one port and one protocol that you are trying to secure then ssh tunneling will suffice. That is assuming you can direct ALL the traffic you want through that tunnel. I have a friend who set up a tunnel to tunnel port 139 so he could mount windows shares at home. Problem is that he could only mount 1 share at a time.
From the sounds of it this is the case.
With ssh tunneling it would be easeier to setup. Anyone could set up the tunnel. With ipsec it is required that one have sysadmin privs or have ipsec set up.
Key exchange is the real thing here. In ipsec keys are required (AFAIK). You can also set up racoon and have auto-exchanging keys. In ssh you have the option to setup keys to be required, but by default they are not. So ssh could be either an encrypted telnet session or it could be a key excehange encrypted session. I always opt for a key exchange session. Personally I go for the more secure the better. Just my parynoia though. It all depends on your level of required security and what you want to secure.
Only 'flamers' flame!
Eventually, the TCP over TCP factor will kick in, and your VPN will be slow
Here's what he means:
FreeS/WAN may not be _The Best_, but it's darn good enough:
I have a system where 12 sizable offices come into a FreeS/WAN router via a 1.5Mbit link, and the VPN moves on average 1Mbit/sec between these offices (sometimes peaks to 1.5Mbit). The VPN router that all 12 networks point to is a Pentium 166 w/ 64MB of ram, the router's been up for over 6 months (an office move required a shutdown 6 months ago), and the VPN only adds around 5 to 10 ms of latency to the connection. Heck, I get better network performance out of this setup, than my old Cisco's did running point-to-point frame-relay.
The FreeS/WAN product can also offload the crypto tasks to hardware devices when really necessary.
SSH is a great secure connection software, not a VPN software. It's can be used to for simple problems, where you want a no hassle portable solution.
IPsec is conceptually much prefered, and also indeed more secure. It is a more complex solution, implementations aren't always stable and are less tested. It is also the standard, if any, for TCP/IP encryption.
SSH should have more overhead for a solution involving the same kind of encryption level and security, and should thus be slower, but this might not be the case in real life. A comparison on an OpenBSD platform would probably be fair, but make sure not to compare a full blown IPsec solution to a simple SSH stream.
Example: You have 10 geographically separated offices...
If you tried to do this using SSH tunnels I would laugh my head off... I'd use OpenBSD/IPsec.
Example: You want to make an existing, specific stream, encrypted.
Tunnel it through SSH.
SSH will only carry TCP traffic. If you need to encrypt anything involving UDP or ICMP (or anything else for that matter), you cannot use SSH to get the job done, except by adding on more clunkiness in the form of things that will encapsulate connectionless protocols within TCP sessions. At that point, you're no longer reaping the benefits of simplicity that come from using something like stunnel, and it's better to bite the bullet and become adept with VPNs (check out FreeS/WAN). On the upside, once you have VPN expertise in hand, you open up a new world of options for other things as well.
For your security, this post has been encrypted with ROT-13, twice.
There are few aspects of SSH vs. IPsec that you seem to be missing:
...
.. or you dont have a budget for a decent IPsec client :)
* first of all, IPsec can go through NAT, no problem. There is a couple of IETF drafts that - define just that IPsec NAT Traversal. Drafts are in their 5th revision, and Cisco, SSH, Nortel and some other manifacturers already support NAT-T and are quite interoperable with each other. Keep in mind though that it's UDP based, and that's the way it must be, because
* TCP-based VPNs (and SSH/SSL tunneling in particular) are prone to a trivial DoS attacks, which severely depricates their robustness. I put a quick paper together that provides a bit more details on the subject.
* keep also in mind that tunneling over SSH leads to TCP-over-TCP encapsulation, which is considered by many 'a bad idea' in general due to the induced TCP retransmission problems.
* you may also consider that SSH comes with a higher average per-packet overhead (due to TCP ACKs), which may require more frequent re-keying when compared to IPsec, which in turn may bring overall VPN performance down.
The bottom line is I would not recommend SSH over IPsec unless it's a time-critical project
3.243F6A8885A308D313
Well, since I work in the infosec industry and have used both myself, they both have their good and bad points.
SSH (the quick and dirty solution)
If all you really care about is encrypting your data and only need to forward a few connections, then SSH is a great candidate. It provides your basic encryption which is a must for security reasons.
However, it is essentially a stopgap measure to tunnel data between client and server. While you can forward as many ports as you have available, you can only tunnel TCP connections (unless you want the IP-over-TCP-over-TCP kludge) and you can only forward a finite amount of connections.
Also, tunneling over TCP is not the preferred method to tunnel connections. While it does provide some method to acknowledge the receipt of a packet, several latentcy problems can occur when TCP-over-TCP tunneling (as the packet overhead starts increasing dramatically if a connection problem occurs).
IPSec
One of the benefits of IPSec is that tunneling connections is no longer a major factor to consider. You can tunnel the entire Internet through IPsec without having to worry how many TCP port forwardings you can configure.
While it may be more difficult to initially setup a working infrastructure, it causes less headaches after it is proven to work properly.
Also, IPSec will work on a NAT connection. As long as your IKE requests (on UDP port 500) are not source port translated when traversing the NAT device, you can establish an IPSec session (and I have got this working myself).
Again, it really depends on what you need it for. For simple jobs, I use SSH. However, it doesn't scale very well, nor does it cover the full range of IP services that IPSec can handle.
I have used both SSH and FreeS/WAN IPsec to tie private networks together. My current setup brings together our two business locations. One location has a cable modem setup, the other DSL. Along with this, I create IPSec tunnels from my home to both locations, so that I can remotely manage those locations via vnc or what ever. My two Linux systems (both P166's) having been running for over 200 days with very few problems, it's been a true set it and forget (but remember it when someone calls ;-)) it deal. If the Internet connection breaks between the two locations IPSec will usually self heal. If not, restarting IPSec at one location almost always clears it up
Because I wanted to tie entire subnets together, SSH was a huge pain in the butt (I used the PPP over SSH method). FreeS/WAN IPSec has been perfect for me allowing me to transfer files between subnets using just about all of the bandwidth available between the connections. Turning on compression helps a lot and works very well, I'm able to transfer a 20 meg file using compression in about 45% of the time it takes when not using compression.
If you're looking to connect roaming users, I suggest PPTP instead of SSH or IPSec. It has it's problems but works nicely for a Windows to Linux VPN. If you have the time and patience, you can get your Linux PPTP server to authenticate against a RADIUS server with PAM support.
SSH to me is for quick 'n dirty tunnels of one protocol at a time and for remote access. If you're looking for a good clean way to tie two or more locations together, then IPSec. If you have roaming Linux or Windows users, then PPTP is the best bet.
I really don't find FreeS/WAN IPSec difficult to get setup considering you can use previous connections as a template for making new ones.