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.
From what I can see if it is Windows, you'll probably have an easier time deploying ipsec. In the land of unix, ssh is sanctum. Sure, there are putty and its workalikes to bring ssh to Windows, but to ask a Windows user to call putty a VPN is asking for trouble.
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.
I've had very poor experiences with IPSEC based products - they tend to be more or less flaky. Also, newer versions of ssh have the ability to run a SOCKS4 server (using the -D option) - I then point Mozilla at that (Chimera is my "regular" browser). Between that and X-windows/vnc, i can do everything i need to and don't have to have some nasty,proprietary client. (Furthermore, everything I need is included in the OS - which means I can get in from just about any computer, anywhere with a net connection.)
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
Over stable links, you're unlikely to have a problem though.
SSH can tunnel any number of ports along with the actual login stream, so you could have multiple ports on your local box that get tunneled through the secure connection. Say your SSH session terminates (through a firewall) to a box on the corporate LAN, and you tunnel IMAP, MySQL, and Squid. Point mutt and mysql to localhost, and point your browser to localhost as a proxy. Voila - you have secure access, no special software required.
Stunnel can do the same thing, and is often faster because it only does the tunneling, and it doesn't need to transmit them all within the same single connection. Stunnel 4.x can handle multiple ports in separate threads like magic. End result though is that you can map the ports/services you actually require, and only those bits are open. Yes, it's not a VPN (unless you want PPP over SSH/SSL, see my comment below), but in most cases you don't need one.
(Weird coincidence: I'll be giving a talk wednesday at real world linux about this very topic, and will be putting up the presentation when I get back. If anyone else is braving SARS in Toronto, stop by and say hi.)
Shouldn't the answer be YES, just use whatever works best.
On a real note the IPsec implementation (free/SWAN) is not the best implementation of IPsec in the world, specifically if you are interested look at the OpenBSD IPsec implementation that takes advantage of crypto offload nics that are commonly available today
I have mod points and I am not afraid to use them
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:
Seriously, you just asked Slashdot for technical advice that may affect the direction your company takes! What the hell are you thinking? Also, be careful about openly announcing the degree of technical knowledge in your company.
Really, you could do a cursory investigation of each tecnhology in one day each.
It ships with the latest redhat distros. Is brain-dead easy to setup. I'm using it now to connect multiple boxes for MySQL replication across the Internet. However, when using Windows workstations, I use puTTY and make SSH tunnels to my remote MySQL, IMAP, POP3, etc servers. I'm interested in IPSec but, sadly, haven't had a lot of success getting it going between platforms.
( Read More... | 1 of 37000 comments )
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.
SSH when you need remote access to applications, and IPSec when you need to aggregate two or more LANs.
Your company makes embedded firewalls? You MAKE firewalls? And you are asking Slashdot if SSH is better than IPSec?
Fortunately, the companies that I purchase firewall and VPN devices from know both of these protocols intimately. Some of them even had a hand in developing the protocols themselves. These companies also know what the pros and cons of each protocol are and which should be used in any give situation. I would expect nothing less from a company that MAKES firewall and VPN devices.
It depends on your intended application.
AFAIK SSH/STunnel implementations tend to be TCP centric. Applications requiring UDP lean towards IPSec flavoured tunnels.
Bottom line MAPI over putty doesn't work (unless you enable OWA and http/tcp at which point there are dozens of more robust options).
- SSH only tunnels specified ports which is a pain if you need to tunnel several services or complicated protocols. Plus it makes things difficult to configure if you're constantly switching between wireless and ethernet on the same system.
- PPPoE (or similar) over SSH can be incredibly unreliable. It's the TCP-over-TCP problem and you will sometimes see connections just freeze up.
- IPsec is a pain in the ass to configure. I've noticed most implementations are pretty crappy. I've seen similar problems that you get with PPPoE over SSH. Connections freezing and such.
- stunnel can't do UDP connections (so no Quake over wireless) among other problems.
I use OpenVPN. It uses UDP and tunnels all traffic like IPsec except it's super easy to configure. In my experience it has also been much more reliable than IPsec. It has several connection and server recovery mechanisms that work very well. I don't think there is a Windows client though so that might be a problem. I really like OpenVPN though.
The ratio of people to cake is too big
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.