On 06/03/14 09:18 PM, Linda Walsh wrote:
Not on a 1Gb link or faster, and I am using ssh and the difference between going through ssh vs. direct is noticeable.
I use ssh between machines on my 1G LAN. It occurs to me that you have choices over which encryption algorithm you can use between specific hosts and whether or not to use compression. It also occurs to me that compression only makes sense when you have more CPU power than network bandwidth. On a LAN I'd turn that off. I can also imagine some very fast WAN links that would be 'faster' than the overhead of compression. However I can't see that there is a "none" listed for an encryption algorithm. None mentioned in ssh_config(5) though I read on the net that there is a source patch to achieve that. You'll need it at both ends. Perhaps using telnet might suffice? Well not for remote X obviously. Maybe socat could do the job? http://www.dest-unreach.org/socat/ There's this example: <quote> socat UNIX-LISTEN:/tmp/.X11-unix/X1,fork \ SOCKS4:host.victim.org:127.0.0.1:6000,socksuser=nobody,sourceport=20 with UNIX-LISTEN, socat opens a listening UNIX domain socket /tmp/.X11-unix/X1. This path corresponds to local XWindow display :1 on your machine, so XWindow client connections to DISPLAY=:1 are accepted. Socat then speaks with the SOCKS4 server host.victim.org that might permit sourceport 20 based connections due to an FTP related weakness in its static IP filters. Socat pretends to be invoked by socksuser nobody, and requests to be connected to loopback port 6000 (only weak sockd configurations will allow this). So we get a connection to the victims XWindow server and, if it does not require MIT cookies or Kerberos authentication, we can start work. Please note that there can only be one connection at a time, because TCP can establish only one session with a given set of addresses and ports. </quote> There are tests for the speeds with various algorithms at http://blog.famzah.net/2010/06/11/openssh-ciphers-performance-benchmark/ I'm sceptical as to whether or not a particular combination in a particular context will meet those speed test examples, though I do recognise that DES is slow and decrepit. And of course that may vary between generations of chips and whether you are using 32 bit or 64 bit at each end. Some algorithms such as AES are going to be '64-bit friendly'. For x86 family chips with encryption hardware see this: http://en.wikipedia.org/wiki/AES_instruction_set and scroll down to see what libraries make use of that. Also http://lwn.net/Articles/14010/ -- The trouble is, if you don't risk anything, you risk even more. - Erica Jong -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org