[Twisted-Python] Why would someone need SSHTransportAddress?

[David Stainton]

It seems like a fairly common idiom to setup some sort of TCP server
with a kernel selected port
via an endpoint descriptor like this:

def getListeningPort(listeningPort):
    address = listeningPort.getHost()
    endpointDesc = convertAddressToEndpointDesc(address)
    sendAnnouncement(endpointDesc)

endpoint = serverFromString(self.reactor, 'tcp:0')
d = endpoint.listen(MyProtocolFactory())
d.addCallback(getListeningPort)

...
later on a remote client receives the endpoint string and uses it to connect:

endpointDesc = getAnnouncement()
endpoint = clientFromString(endpointDesc)
endpoint.connect(MyFactory())

For the Tor Hidden Services endpoint (work in progress) I've
implemented IAddress and IListeningPort:
https://github.com/david415/txtorcon/blob/endpoint_parser_plugin-rewrite4/txtorcon/torconfig.py#L106-L160

Creating a Tor Hidden Service endpoint without specifying a "hidden
services directory" containing an rsa private key and a hostname file
causes the endpoint object to create a new Tor Hidden Service. This is
conceptually similar to the case where we create a TCP server endpoint
with the port number set to zero. In both cases the fired
IListeningPort implementation should tell us what we need to know in
order to construct a client endpoint descriptor string.

I was thinking that it would be great if the process of creating these
endpoint strings from an IAddress implementation should/could be
endpoint agnostic. It should work even if the endpoint descriptors
have no notion of hosts or ports... For protocols like TCP it is
non-obvious how to do this correctly because the host cannot be
correctly guessed in the face of NAT routers etc... as mentioned here:
https://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.ITransport.html#getPeer

This is why the above TCP example is flawed; however the equivalent
example with the Tor endpoints will work perfectly and is not affected
by NAT routers:
https://github.com/david415/txsocksx/blob/tor_deferred_dispatcher/examples/tor-dispatch-onion.py#L39-L63

The TorOnionAddress has all the information it needs to create a Tor
client endpoint... except for the endpoint type identifier and a set
of rules from constructing endpoint strings... which perhaps the
TorOnionAddress should get from the TCPHiddenServiceEndpointParser?
Perhaps if the user were to pass in more information to the server
endpoint object then the TCP IListeningPort implementation would be
able to correctly produce a TCP client endpoint strings. Or maybe this
just doesn't make sense for protocols like TCP.



On Mon, May 19, 2014 at 3:59 PM,  <exarkun at twistedmatrix.com> wrote:
> On 06:27 am, adi at roiban.ro wrote:
>>
>> This email is bases on comment from
>> https://twistedmatrix.com/trac/ticket/5999
>>
>> I fail to see the reason why SSHTransportAddress exist and why would
>> anyone need It.
>
>
> Here are a couple ideas.
>
> You have a library that accepts a connection and does some things with it.
> You want to log the operations that are taken using the connection and you
> want to include information in those logs about which connection you did
> things with.  You choose to use the addresses of the local and remote sides
> of the connection to identify it.
>
> You have a library that accepts a connection and wants to be able to set up
> another connection like it to the same remote address.  You get the remote
> address using the transport's `getPeer` method.
>
> Though you may have established the SSH connection over a TCP/IPv4
> connection, neither of these uses can be accomplished if the SSH connection,
> when treated as a transport, merely uses an `IPv4Address` instance to
> represent the address of the remote end of the connection. Using
> `IPv4Address` gives you no way to differentiate between an SSH connection
> running over a TCP/IPv4 connection and a plain TCP/IPv4 connection without
> SSH.
>
> In practice, `SSHTransportAddress` is missing the information you would need
> to implement either of these scenarios.  However, that seems more like an
> argument for adding the missing information to that address type rather than
> discarding the address type.
>
> Jean-Paul
>
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python