OpenSSH Patch Extends Tunneling Under OpenBSD 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. :)"
Balance of Perf and Ease? (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:3, Interesting)
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.
Obvious (Score:2, Interesting)
Re:Balance of Perf and Ease? (Score:3, Interesting)
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? (Score:3, Interesting)
Re:Balance of Perf and Ease? (Score:2, Interesting)
Re:Balance of Perf and Ease? (Score:2, Insightful)
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 pa
Parent is good. Here it is with my bonus. (Score:2)
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 pe
Re:Balance of Perf and Ease? (Score:2)
No worries.
Re:Balance of Perf and Ease? (Score:2)
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! (Score:2)
You beat me to it! (Score:2)
Of VPN's and Legalities... (Score:2, Interesting)
Re:VPN's illegal?!?` (Score:1)
Re:Of VPN's and Legalities... (Score:1)
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 yo
Null encryption? (Score:3, Interesting)
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? (Score:4, Informative)
Otherwise, you can always use blowfish, rc4, or even AES (I think...) as they are all *MUCH* faster than 3des.
sedawkgrep
Re:Null encryption? (Score:5, Insightful)
Thanks for the tip. You learn something every day on this board!
Re:Null encryption? (Score:4, Informative)
I wonder if a plaintext cipher would compromise authentication. (Not that it matters in this case.)
Re:Null encryption? (Score:2)
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.
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
Re:Null encryption? (Score:2)
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? (Score:2)
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.
Well, if you are using public-key auth (wouldn't recomend using ssh-
Re:Null encryption? (Score:2, Insightful)
Re:Null encryption? (Score:1)
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? (Score:3, Interesting)
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.
Re:Null encryption? (Score:2)
Small error in the examples... (Score:4, Informative)
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
The next example is correct (and shows the use of the patch).
Just my 0.02
Re:Small error in the examples... (Score:1)
Re:Another Small error in the examples... (Score:1)
Re:Small error in the examples... (Score:1)
- 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(...) ).
Another approach for "transparent proxying" (Score:2)
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 neede
What's wrong with port forwarding? (Score:1)
--Quentin