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."
ssh.
As a consultant I've had to work with different remote access solutions, and everything except for ssh is a huge pain in the ass. Some of them don't work with anything but Windows, and most of them are too complicated for a large organization to figure out. If you're a big company and you don't want to frustrate your users, go with ssh. Otherwise, you're going to condemn everyone who wants to get hooked up to at least 4 weeks of phone call support hell.
If tits were wings it'd be flying around.
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.
ssh has the advantage of having very little setup and is uber portable. problem is, you can't encrypt an entire line easily,
The cheapo VPN solution that springs to mind in this case is something like running PPPoE on the ssh connection like this.
I haven't done this, so I don't know whether this is easy or hard to setup. Someone here must know.
"Provided by the management for your protection."
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.