×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenSSH Patch Extends Tunneling Under OpenBSD

timothy posted more than 10 years ago | from the open-open dept.

Security 38

Jonatan Wallmander writes "We've written a small howto as well as produced a simple patch for OpenSSH that improves tunneling functionality in the ssh client on the OpenBSD platform (this should be OK on other platforms with some tweaking). It's a simple hack but works very good for us. We can have different IPs on the same BSD machine tunnel different hosts ... Without the patch you can only have one tunnel per BSD machine since it listens on INADDR_ANY.. Now all my computers on the LAN can access remote servers securely as if they were in the same room provided by a single BSD server. :)"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

38 comments

Balance of Perf and Ease? (4, Insightful)

4of12 (97621) | more than 10 years ago | (#5889855)


I got educated on an earlier Slashdot story of how (a) how nice and easy it was to set up an encrypted tunnel using ssh instead of IPSec or a weird proprietary VPN product, (b) how TCP over TCP is a fundamentally bad idea and people were compensating by periodically restarting the tunnel service afresh to work around it.

How's the performance of this setup and does it address any of those problems?

TCP over TCP OK (4, Insightful)

bill_mcgonigle (4333) | more than 10 years ago | (#5891252)

TCP over TCP is a fundamentally bad idea

There may be some theoretical basis to this mantra, but in the real world it doesn't apply. I develop a product that uses TCP/TCP communications and it transfers hundreds of gigs a week from dozens of sites without any performance problems.

I think the way the real world works around the theoretical problems is that it's not really possible to maintain a TCP connection on the 'net for a long period of time unless you control the entire path. In my case, customer sites are always rebooting their routers, NAT boxes, etc. and connections rarely last longer than a day, often only several hours.

Fortunately, Unix has nice mechanisms for keeping things up, i.e. inittab.

Re:TCP over TCP OK (2, Interesting)

sporty (27564) | more than 10 years ago | (#5893623)

I wouldn't be surprised if you saw like, a 1% increase if you used straight tcp/ip.

tcp over tcp incures an x% size of packet increase. Reminds me of that stupid commerial. "We saved a nickel for a transaction" The go on and on about this stupid nickel and then they talk about how they do "20 million in transactions a day."

But hey, if you have the bandwidth, knock yourself out. :) If it works, it works.

Obvious (2, Interesting)

mindstrm (20013) | more than 10 years ago | (#5898368)

Protocol overhead is obvious.. the real issue that people talk about is to do with how TCP deals with congestion... you end up with 2 layers of protocol trying to deal with a problem when only one needs to.. leading to some interesting issues... (things can theoretically get really slow)

Re:Balance of Perf and Ease? (2, Interesting)

evilviper (135110) | more than 10 years ago | (#5891721)

TCP over TCP a problem? I think not. You are probably thinking about OTHER things over TCP. UDP tunneling can have it's problems when there is a bandwidth crunch on the TCP connection.

TCP over TCP is just as good as regular TCP, even if it's a bit slower due to encryption (but compression makes it up to some extent).

Re:Balance of Perf and Ease? (2, Interesting)

QuMa (19440) | more than 10 years ago | (#5892383)

Depends on where the endpoints are. If you're generating the packets and stuffing them into a tcp tunnel on the same host you're fine. If your packets get out of order/dropped/whatever before they enter the tunnel you're still screwed though.

Re:Balance of Perf and Ease? (2, Interesting)

mindstrm (20013) | more than 10 years ago | (#5898382)

No.. the reason tcp over tcp has issues is because you end up with both tcp layers trying to backoff and deal with congestion and retransmits rather than one, and things can happen such that the two layers start interfering with each other rather than helping. (one layer transmits, then another does, causing even more extra packets, etc)

Re:Balance of Perf and Ease? (2, Insightful)

Anonymous Coward | more than 10 years ago | (#5894769)

ARG! All the replies to this post so far are so wrong that it's hurting my brain.

1. yes "TCP over TCP" is a bad effect. This is what happens when you tunnel an unreliable protocol (like IP encapsulated in PPP) over a reliable protocol (like TCP with something like SSH or SSL on top) The problem is that packet loss ends up causing retransmits both from the encapsulated TCP sessions and from the SSH/SSL layer on top. So you end up with a situation where it works perfectly when you're getting near zero packet loss, but as soon as there's even a moderate amount of packet loss the entire connection falls apart. Often the only way to recover from this is to restart the tunnel.

2. However, THIS ARTICLE ISN'T ABOUT THAT. It's using ssh'd builtin TCP forwarding to tunnel the data. So instead of "TCP-over-TCP" it's "TCP-to-TCP-to-TCP". At to point in the connection are there two TCP state machines both competing to retransmit. I'm sorry if this doesn't make much sense in text - I really need a whiteboard to explain it properly.

The short version is that the "TCP-over-TCP" problem is basically confined to schemes where they try to tunnel a PPP session over SSH (in order to get a full VPN). Just using SSH's port forwarding is _fine_.

Parent is good. Here it is with my bonus. (1)

Beryllium Sphere(tm) (193358) | more than 10 years ago | (#5898316)

I'm reprinting something from an AC which got stuck at 0 despite being informative. I've dropped the first sentence.

cut here

1. yes "TCP over TCP" is a bad effect. This is what happens when you tunnel an unreliable protocol (like IP encapsulated in PPP) over a reliable protocol (like TCP with something like SSH or SSL on top) The problem is that packet loss ends up causing retransmits both from the encapsulated TCP sessions and from the SSH/SSL layer on top. So you end up with a situation where it works perfectly when you're getting near zero packet loss, but as soon as there's even a moderate amount of packet loss the entire connection falls apart. Often the only way to recover from this is to restart the tunnel.
2. However, THIS ARTICLE ISN'T ABOUT THAT. It's using ssh'd builtin TCP forwarding to tunnel the data. So instead of "TCP-over-TCP" it's "TCP-to-TCP-to-TCP". At to point in the connection are there two TCP state machines both competing to retransmit. I'm sorry if this doesn't make much sense in text - I really need a whiteboard to explain it properly.
The short version is that the "TCP-over-TCP" problem is basically confined to schemes where they try to tunnel a PPP session over SSH (in order to get a full VPN). Just using SSH's port forwarding is _fine_.

Re:Balance of Perf and Ease? (1)

sshore (50665) | more than 10 years ago | (#5907281)

TCP over TCP is a fundamentally bad
This isn't actually TCP over TCP. The connection is made to the local agent, and only the data, not the TCP headers, go over the tunnel.

No worries.

Re:Balance of Perf and Ease? (1)

halfelven (207781) | more than 9 years ago | (#6002312)


TCP over TCP is a fundamentally bad idea


It is true on not-so-reliable networks.
It is false on the modern, low-loss Internet.

Excellent idea! (1)

Hanashi (93356) | more than 10 years ago | (#5889856)

I read the paper, and found it to be a very elegant solution to the problem. I, too, have wished to have multiple tunnels on the same port. I only hope that this patch makes it into OpenSSH (and OpenSSH-portable, of course). I think it'll need some testing, but it seems like a good idea well executed.

You beat me to it! (1)

BoomerSooner (308737) | more than 10 years ago | (#5890209)

Ditto. Keep up the good work. I'm new to BSD (from Linux/Solaris) but I've been very impressed so far.

Of VPN's and Legalities... (2, Interesting)

bonsai_kitty (636771) | more than 10 years ago | (#5889944)

This is an excelent idea and better yet sounds like it will work to bridge the OS gap. But is this considered a VPN? And if so should I be concerned about "The Long Arm" if I attempt it with a node in a state that prohibates such.

VPN's illegal?!?` (0)

Anonymous Coward | more than 10 years ago | (#5890503)

I didn't know that there were any states that had outlawed VPN's. Do tell!

Re:VPN's illegal?!?` (0)

Anonymous Coward | more than 10 years ago | (#5910749)

It's called the Super DMCA. Search /. for it. There was a sfcronicle article on it a while back. It's scary.

Re:Of VPN's and Legalities... (1)

Zebra_X (13249) | more than 10 years ago | (#5907728)

No I don't think that you should be concerend about this. The law is vague about how what constitutes "hiding" the point of orgin of comunication.

A better way to look at it is this: you have a tunnel which has an orgin and an enpoint. Both of which are known physical locations, further more the computer that you are likely communicating with is also "known" becuase it's connected to a LAN which is in turn connected to a tunnel end point - which is a known location, not just to you, but at the very least your service provider. It's not as if you are trying to hide or even succeding in "hiding" the point of orgin for your communication.

I imagine that someone will go to court with this but it's not going to hold up - becuase communications networks require physical devices to do the communication and especially in the LAN->Internet scenario the origin of that communication is almost always known. Now bulding a tunnel from a cell phone, then from multiple servers and clearing out the log entries is something else...

Null encryption? (2, Interesting)

Euphonious Coward (189818) | more than 10 years ago | (#5890074)

This is slightly off-topic...

The OpenSSH sources list a "null" cipher, but I have had no success in establishing a connection using it. Is there a trick to it, or do I need to patch the sources to get a connection that sends in plaintext?

(Why? The traffic is already encrypted via IPSEC; I just want to use SSH's cool port-forwarding apparatus and its authentication, and don't want to pay for for encrypting twice.)

Re:Null encryption? (3, Informative)

sedawkgrep (142682) | more than 10 years ago | (#5890751)

While I haven't done this in YEARS, I think you need to add a Ciphers line to /etc/ssh/sshd_config that contains 'none'. Be sure to include all the ciphers you may want to use because this list is exclusionary.

Otherwise, you can always use blowfish, rc4, or even AES (I think...) as they are all *MUCH* faster than 3des.

sedawkgrep

Re:Null encryption? (4, Insightful)

Deagol (323173) | more than 10 years ago | (#5891764)

Holy crap... I didn't realize that openssh defaulted to 3des (at least in Redhat RPMs). I forced both my server and clients to use blowfish and the interactive lag over my 33.6 modem connection dropped considderably.

Thanks for the tip. You learn something every day on this board!

Re:Null encryption? (3, Informative)

Euphonious Coward (189818) | more than 10 years ago | (#5892337)

Thanks, I had tried that. I have a Ciphers line in my /etc/ssh/sshd_config already, so it will default to aes128-cbc, fall back to blowfish-cbc, and finally 3des-cbc. When I add "none" or "null", sshd complains when it reads the file: Bad SSH2 cipher spec.

I wonder if a plaintext cipher would compromise authentication. (Not that it matters in this case.)

Re:Null encryption? (1)

evilviper (135110) | more than 10 years ago | (#5896736)

Bad SSH2 cipher spec.

That's the message you get when you've typed the name of the cipher incorrectly... Try the name followed by "-cbc", and I bet you'll have better luck.

I wonder if a plaintext cipher would compromise authentication. (Not that it matters in this case.)

Indeed it does, and more. With no encryption, there is no authentication, and no verification. So, not only can someone read your password, or intecept the challenge-response if you are using a cert or the ssh-agent, but someone could very easilly spoof the source address of a specially crafted packet, and, in turn, have that command executed as the logged-in user on the SSH server... This could work the other way around as well. Someone could make a packet that claims to be the server, and that data would be inserted into the data recieved by the client. Screen output, corrupting binary file transfers, whatever.

You didn't mention much about this, so I'm not sure if this is a concern for you. Also, I wonder why you would use SSH's port-forwarding... There are alternatives (depending on what you are doing with it) if you don't want the authentication/encryption.

Re:Null encryption? (1)

Euphonious Coward (189818) | more than 10 years ago | (#5897301)

Adding ",none-cbc" to the ciphers list had the same result as just ",none" -- sshd rejected it.

It's not obvious that a null cipher must compromise authentication, and I can think of lots of uses for a channel that's authenticated but not bulk-encrypted, even without assuming that the channel is encrypted by IPSEC.

Re:Null encryption? (1)

evilviper (135110) | more than 10 years ago | (#5897947)

Adding ",none-cbc" to the ciphers list had the same result as just ",none" -- sshd rejected it.

Hmm, I was just assuming OpenSSH imitated the commercial versions... After a quick search on google, I did find this patch against OpenSSH [membled.com]. Seems a rather simple change to get enencrypted connections working. I guess the OpenSSH guys just want to save users from themselves.

It's not obvious that a null cipher must compromise authentication,


Well, if you are using public-key auth (wouldn't recomend using ssh-agent in such a situation), you should be okay authentication-wise. But that's besides the point.

If the SSH connection is *entirely* going over an IPSec connection, there shouldn't be any problem. SSH won't be encrypting/authenticating the source, but IPSec should be able to do that part well enough.

Re:Null encryption? (1)

ViVeLaMe (305695) | more than 10 years ago | (#5899726)

null encryption can be useful in the folllowing case:
you use public key auth and you like to use scp to automate some file transfers on your own network.
encryption can be quite a burden, and it's nice to be able to specify a null cipher on the command line when you know the files you transfer aren't especially sensitives.

Re:Null encryption? (2, Interesting)

evilviper (135110) | more than 10 years ago | (#5902491)

Possibly, but you'd better make a checksum on the source, and verify it at the destination. Encryption (even if you only use 40-bit rc4, or something equally weak) allows the client and server to verify the data is not corrupted, as well as preventing casual evesdroping...

I would sugest you look into using some weaker encryption modes, rather than none at all. If CPU power is an issue, crypto accelerators seriously improve performance, and can often be very cheap.

Small error in the examples... (3, Informative)

Gruturo (141223) | more than 10 years ago | (#5890425)

I don't wish to be pedantic, and it doesn't compromise the understandability of the article, but in the drawing under chapter 3 (The basic solution), the "brown" OpenBSD file server is available to the Windows PC as .200, and NOT .5 as suggested.
The green OpenBSD box just does a simple port forwarding (from its own 139 to port 139 on 127.0.0.1 seen from the other endpoint's perspective) and makes it available non-loopback-only via the "-g" option (which btw won't work if you don't have "GatewayPorts yes" in your sshd_config file, and the last time I checked this was not exactly well documented). Therefore, 192.168.0.200:139 (actually 0.0.0.0:139, esp. without this patch :-) ) gets mapped to 127.0.0.1:139 (but on the OTHER end of the tunnel - thus the brown box).

The next example is correct (and shows the use of the patch).

Just my 0.02

Re:Small error in the examples... (1)

jonatanw (667696) | more than 10 years ago | (#5890783)

thanks mate.. updated the picture to make things more clear. I also updated the title a bit..

Re:Another Small error in the examples... (1)

ScooterComputer (10306) | more than 10 years ago | (#5910032)

Actually the second example shows an IP address of 192.168.1.46:139 for the friend's OBSD server in the diagram, but the affiliated command line (the second line) uses 192.168.0.10:139 for it.

Re:Small error in the examples... (1)

gskc (661798) | more than 10 years ago | (#5922989)

Actually there is an bug in their patch too! Here is my patch to their patch for ssh.c :)

- options.gateway_addr = malloc(strlen(optarg));
+ options.gateway_addr = malloc(1 + strlen(optarg));
sprintf(options.gateway_addr,"%s",optarg);

You never know, this could lead to a buffer overrun and a possible exploit (options.gateway_addr is last seen going into getaddrinfo(...) ).

lamentations of the dying: What Killed FreeBSD (-1, Troll)

Anonymous Coward | more than 10 years ago | (#5890426)

The End of FreeBSD

[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]

When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.

Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.

FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.

It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.

So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.

Discussion

I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.

From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.

There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.

Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.

Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?

Shouts

To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.

To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It's when you get distracted by the politickers that they sideline you. The tireless work that you perform keeping the system clean and building is what provides the platform for the obsessives and the prima donnas to have their moments in the sun. In the end, we need you all; in order to go forwards we must first avoid going backwards.

To the paranoid conspiracy theorists - yes, I work for Apple too. No, my resignation wasn't on Steve's direct orders, or in any way related to work I'm doing, may do, may not do, or indeed what was in the tea I had at lunchtime today. It's about real problems that the project faces, real problems that the project has brought upon itself. You can't escape them by inventing excuses about outside influence, the problem stems from within.

To the politically obsessed - give it a break, if you can. No, the project isn't a lemonade stand anymore, but it's not a world-spanning corporate juggernaut either and some of the more grandiose visions going around are in need of a solid dose of reality. Keep it simple, stupid.

To the grandstanders, the prima donnas, and anyone that thinks that they can hold the project to ransom for their own agenda - give it a break, if you can. When the current core were elected, we took a conscious stand against vigorous sanctions, and some of you have exploited that. A new core is going to have to decide whether to repeat this mistake or get tough. I hope they learn from our errors.

Future

I started work on FreeBSD because it was fun. If I'm going to continue, it has to be fun again. There are things I still feel obligated to do, and with any luck I'll find the time to meet those obligations.

However I don't feel an obligation to get involved in the political mess the project is in right now. I tried, I burnt out. I don't feel that my efforts were worthwhile. So I won't be standing for election, I won't be shouting from the sidelines, and I probably won't vote in the next round of ballots.

You could say I'm packing up my toys. I'm not going home just yet, but I'm not going to play unless you can work out how to make the project somewhere fun to be again.

= Mike

--

To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt

DUPE! I already read this HERE: (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#5897501)

Are you bright? witty? Do you have friends that laugh at your jokes? We at lrse hosting" [lrsehosting.com] are looking for a select few individuals to join our ranks at the internet's premier source of wit [sporks-r-us.com] and style [geekizoid.com].

Do YOU have what it takes? Register TODAY and FIND OUT!!!!

Another approach for "transparent proxying" (1)

stefanb (21140) | more than 10 years ago | (#5908927)

I just had to set up something similar, to be able to access a couple of machines at a client's site, and the client didn't want a real VPN.

The OpenSSH client has the nice feature of being able to act as a SOCKS4 proxy to dynamically build tunnels through a connection. What this means is that you don't have to specify every single forwarding when starting ssh, but you can use a socksified client to connect to ssh(1) and establish further tunnels on an as-needed basis.

Now, my (proprietary) software needed for this project is not socksified. What now? Ah! PFs rdr rules! (Also possible with IPFilter, IPFW (FreeBSD), IPChains...)

My client's private network address does not clash with the ones I use, so I set up my OpenBSD router to redirect TCP packets destined for the client's network to a local port. From there, transproxy (/usr/ports/www/transproxy) picks up the connection, and forwards it through the ssh(1) SOCKS4 proxy to the appropriate machine on the client's network.

The only thing left was to copy the client's private DNS zone over to my internal nameserver to be able to resolve names properly, and e voila!, I had my (almost) transparent ssh-based VPN.

The currect version of transproxy [nlc.net.au] doesn't support SOCKS4, but I've submitted patches to the author. In the meantime, you can find my patches here [hanse.de].

What's wrong with port forwarding? (1)

CoolQ (31072) | more than 10 years ago | (#5925791)

Can't you just tunnel to a different local port and use port forwarding or redir to map 139 on the proper interface to whatever you connected the tunnel to? It seems the patch is unnecessary...
--Quentin
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...