SSH or IPSec? 43
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."
And the answer is... (Score:4, Interesting)
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.
Re:And the answer is... (Score:2)
And never use a VPN when.... (Score:4, Insightful)
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.)
Re:And never use a VPN when.... (Score:3, Funny)
Joe
Re:And the answer is... (Score:1)
http://vtun.sourceforge.net/ [sourceforge.net]
Works like a charm, setup is a breeze, just need port 5000 (or whatever u choose) open on the firewall from authorised clients.
We use tightVNC and ssh and webmin etc over the link.
no worries.
Soon to bump this up to 100 sites
depends on what OS your clients are running (Score:2, Insightful)
SSH is my preference (Score:5, Informative)
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.
Re:SSH is my preference (Score:3, Interesting)
Yes TCP over TCP not good, but not bad. (Score:5, Informative)
Over stable links, you're unlikely to have a problem though.
Re:SSH is my preference (Score:2)
I'm very interested in this - could you go into a bit more detail or provide a link to some documentation? I've used vtun (vtun.sf.net) for years and years, and it is handy, but I'm always interested in other approaches.
Re:SSH is my preference (Score:1, Flamebait)
Dave
Re:SSH is my preference (Score:1)
Who are you to judge me?
More over, how does one picture of a single event have any bearing at all on my knowledge or anything else other than the event itself?
Is this honestly the best place to even have this discussion?
Re:SSH is my preference (Score:2)
True, except that was was accompanied by at least one picture driving into Auckland - that, to be honest, I could have *sworn* claimed to have been taken at 180K.
More over, how does one picture of a single event have any bearing at all on my knowledge or anything else other than the event itself?
It was on the website referenced in your public information on slashdot. The site's tagline is "Korgan's news ram
Both (Score:4, Informative)
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?
Re:Both (Score:1, Informative)
not the ssh telnet replacement only.
Re:Both (Score:5, Informative)
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 [geocrawler.com].
I haven't done this, so I don't know whether this is easy or hard to setup. Someone here must know.
PPP over SSH/SSL/etc (Score:5, Informative)
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 [buildinglinuxvpns.net], 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 [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 [hackinglinuxexposed.com] including using authprogs [hackinglinuxexposed.com] 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.
Why TCP over SSH is a bad idea (Score:5, Informative)
Eventually, the TCP over TCP factor will kick in, and your VPN will be slow
Here's what he means:
Re:PPP over SSH/SSL/etc (Score:2)
I prefer ssh (Score:3, Interesting)
Almost as silly as asking (Score:2)
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
Re:Almost as silly as asking (Score:5, Informative)
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 [freeswan.org] the crypto tasks to hardware devices when really necessary.
Re:Almost as silly as asking (Score:2)
I don't think you could get that out of a 4 way Xeon system
Re:Almost as silly as asking (Score:1, Funny)
Re:Almost as silly as asking (Score:1)
Regarding a webserver only dealing with 1Mbit/sec of traffic - yes I believe this
Re:Almost as silly as asking (Score:2)
Also the current IPsec NIC from Intel costs 60 bucks. Can't plug it into FreeSWAN, but Oh well
Re:Almost as silly as asking (Score:1)
For the NICs, I was thinking gigabit IPSec NICs. Either way, my point was that IPSec enabled NICs were pennies compared to the monthly cost of say an OC12. Look at it this way; if you can save your company $30k+ on not havin
depends on how... (Score:5, Informative)
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.
What about cipe? (Score:1)
SSH vs IPsec (Score:4, Informative)
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.
What do you need to encrypt? (Score:3, Informative)
.. data is as secure in one or the other (Score:4, Informative)
* first of all, IPsec can go through NAT, no problem. There is a couple of IETF drafts that - define just that IPsec NAT Traversal [ietf.org]. 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 [cipherica.com] 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' [sites.inka.de] 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
It all depends on what you need it to do. (Score:3, Informative)
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.
You're kidding right?????? (Score:2, Funny)
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.
Et tu UDP? (Score:1)
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).
What systems must you support? (Score:1)
- 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
I've done both (Score:2, Informative)