[Zope-dev] OpenSSH configuration between ZEO clients & storage server

[Adam Manock]

At 12:01 PM 3/27/02, Itamar Shtull-Trauring wrote:
>Shane Hathaway wrote:
>
>>But you don't need reliability compensation to multiplex.  SSH assumes 
>>the transport layer is reliable.  So an SSH tunnel and an SSL tunnel are 
>>virtually synonymous.
>
>They're not really, but yeah, I was wrong :)
>
>A SSL forwarder takes a packet, and then sends over another TCP connection 
>that happens to be encrypted. It's basically a TCP port forwarder. 
>Multiple client connections through the local SSL forwarder (e.g. stunnel) 
>will run over *multiple* outgoing streams:
>
>client --> stunnel on localhost ---> stunnel on www.foo.com ----> server 
>on www.foo.com
>
>SSH OTOH uses a multiplexing protocol, where multiple streams of data run 
>over the same connection, and each have their own flow control. Multiple 
>client connections over a SSH port forwarder will run over the same 
>*single* stream.
>
>A third thing is TCP over TCP, i.e. PPP over SSH or SSL, which functions 
>as a full network connection.
>
>>The Python standard library has good support for an SSL client but not 
>>for an SSL server.
>
>pyOpenSSL is good for both servers and clients. Could be better, but it's easy
>to start using it, especially for select() based servers (its thread-safety
>is iffy). Twisted's SSL stuff uses it, and latest version of pyOpenSSL may 
>have asyncore example.
>

Yes. The best solution would be for the ZEO protocol to support auth and 
crypto natively...
The next best solution (while you wait) is to use CIPE ;-)

As far as I understand it, even regular TCP port forwarding is TCP over TCP 
and suffers from the unreliable carrier assumption causing excess (eg 
retransmit) traffic over a reliable channel.

Consider:
host <--TCP--> local interface <--TCP tunnel--> local interface <--TCP--> host
host <--TCP-->                  virtual loopback 
interface              <--TCP--> host

In this common port forwarding scenario, the SSH or SSL tunnel creates a 
virtual single loopback interface that
the two hosts use to talk to each other, using TCP. The transport that 
joins these two physical interfaces to create one virtual loopback 
interface is also TCP. Therefore it's TCP over TCP

How much pain this will cause you in the real world really depends on your 
bandwidth and packet loss rates.

If anyone is aware of any special handling that ssh or stunnel does to 
prevent or reduce duplicate TCP flow control / adaptive retransmission / 
congestion control, please let me know.

Adam