Netcat mode on OpenSSH
blog.rootshell.be
Netcat mode on OpenSSH
1–7 of 7 posts
Re: Netcat mode on OpenSSH
#2Currently, just open one term window to do the 'ssh -L', and a second window to do the 'nc'.
This enhancement just saves me the trouble of opening a term window.
Re: Netcat mode on OpenSSH
#3Currently, just open one term window to do the 'ssh -L', and a second window to do the 'nc'. This enhancement just saves me the trouble of opening a term window.
Well, the big advantage is it doesn't listen on a port, which means if the system in question has a crazy local firewall policy, this works better. Also, on a multi-user system, this is more secure as other users cannot connect to this port.
Plus, I'd rather use one command than two, makes scripting easier.
Re: Netcat mode on OpenSSH
#4Aw man, I was hoping this would be a passthrough mode for the transport.
Sometimes I'd like to have secure authentication but otherwise have no encryption — the overhead is way too high on slower boxes when you have a good amount of bandwidth available. One classic case I'd run into is using a nice old Sparc workstation as a remote X terminal to a fast new box: if I used SSH to forward the X session its process would regularly spike the local CPU, so I would end up just using a completely insecure X server instead.
It can be too slow even on decently fast boxes when you have gigabits of bandwidth available — I'd just end up piping tar through netcat to avoid the overhead.
Re: Netcat mode on OpenSSH
#5Aw man, I was hoping this would be a passthrough mode for the transport. Sometimes I'd like to have secure authentication but otherwise have no encryption — the overhead is way too high on slower boxes when you have a good amount of bandwidth available. One classic case I'd run into is using a nice old Sparc workstation as a remote X terminal to a fast new box: if I used SSH to forward the X session its process would…
I wonder how much of this is just because you're using a slow encryption function. On my (quite fast) machine, the default 128-bit AES encryption can handle a little under 800 Mbit/s. Meanwhile, Threefish-512 can encrypt at 4 Gbit/s on the same machine, with what we lightheartedly hope is an equal or greater amount of security. And if you use CTR mode for block chaining, you can parallelize it among however many cores you have, for several times speedup -- my quad-core machine could manage 16 Gbit/s with Threefish-512 in CTR mode, which is really quite zippy.
What I'm saying is, faster transfers should be possible. And they probably already are, if you're willing to find out how to tweak the OpenSSH settings. Maybe.
Re: Netcat mode on OpenSSH
#6A really useful thing I use with ssh and netcat is to forward SSH connections through a bastion host like this - http://backdrift.org/transparent-proxy-with-ssh
It looks like netcat can be substituted with the openssh 5.4 builtin.
Re: Netcat mode on OpenSSH
#7Aw man, I was hoping this would be a passthrough mode for the transport. Sometimes I'd like to have secure authentication but otherwise have no encryption — the overhead is way too high on slower boxes when you have a good amount of bandwidth available. One classic case I'd run into is using a nice old Sparc workstation as a remote X terminal to a fast new box: if I used SSH to forward the X session its process would…
You want the HPN-SSH cipher-none patch:
http://www.psc.edu/networking/projects/hpn-ssh/
Although even the HPN-SSH project recommentd using MT-AES-CTR on multicore machines to get encryption and saturate a 1GBit link.