[Question] Generalized alternative of ProxyCommand

[isidentical]

There is a ProxyCommand class is paramiko which acts like the ProxyCommand directive on the ssh config.

This class implements a the socket-like interface needed by the Transport and Packetizer classes. Using this class instead of a regular socket makes it possible to talk with a Popen’d command that will proxy traffic between the client and a server hosted in another machine.

When creating a new connection, we pass it as the socket that is going to use. E.g;
https://gist.github.com/ovidiucs/e0aebf203f9280ead466#file-paramiko-proxy-py-L38

The class basically acts as a socket-like interface and on send() calls send the data to the stdin of the started subprocess (which is the proxy command) and on read() calls it reads the data from the stdout. See the implementation here;
https://github.com/paramiko/paramiko/blob/d2d3d77395d1079a2e335080b7f9f79d3f70ad2a/paramiko/proxy.py#L71-L119

I thought about implementing a similar class (perhaps using async subprocesses, to make the send/recv non-blocking) though I don't know if there is anything I should be concerned about (does asyncssh use anything besides a regular send/recv on the sockets for example?). I've seen your answer on here #104 (comment) which shows how to pass an external socket to proxy the connection over, so I intend to use that example as the base. If you have any suggestions / or stuff that I should keep in mind while implementing, I'd appreciate it.

[ronf]

Here's an example of how to connect a SOCKS proxy into AsyncSSH using a pattern similar to #104, but with the "aiosocks" library providing the socket I/O in a form that's compatible with asyncio:

import aiosocks, asyncio, asyncssh, sys

class SOCKSClientConnection:
    def __init__(self, proxy, proxy_auth=None):
        self._proxy = proxy
        self._proxy_auth = proxy_auth

    async def create_connection(self, session_factory, host, port):
        return (await aiosocks.create_connection(session_factory,
                                                 proxy=self._proxy,
                                                 proxy_auth=self._proxy_auth,
                                                 dst=(host, port)))

async def run_client():
    tunnel = SOCKSClientConnection(aiosocks.Socks5Addr('localhost', 1080),
                                   aiosocks.Socks5Auth('socksuser', 'sockspw'))

    async with asyncssh.connect('localhost', tunnel=tunnel) as conn:
        result = await conn.run('ls abc')
        print(result.stderr, end='')

try:
    asyncio.get_event_loop().run_until_complete(run_client())
except (OSError, asyncssh.Error) as exc:
    sys.exit('SSH connection failed: ' + str(exc))

As long as you can return a (transport, protocol) pair from the create_connection() call that allows you to do I/O to a subprocess you should be able to pass the resulting custom ClientConnection object into AsyncSSH using the "tunnel" parameter. I think in this case you'd probably need to define your own transport and protocol classes, which you'd then delegate to transparent/protocol objects associated with the subprocess stdin/stdout.

That said, the asyncio subprocess functions are associated with stream objects, not transports/protocols. You might be better off using the standard OS subprocess functions to create your subprocess and then the loop.create_read_pipe() and loop.create_write_pipe() functions to get back (transport, protocol) pairs. Some adaption would still be required, since you need to return a single transport/protocol that will work for both input and output. However, it'll be easier to do the delegation with existing transport and protocol objects than it would to try and do so using the StreamReader/StreamWriter objects returned as part of the asyncio.subprocess.Process() class.

The tricky thing about trying to adapt things at the send() and recv() level is that you'd need to have your own coroutine blocked in recv() that converted the returned data into data_received() callbacks for AsyncSSH. If you can use the event loop functions to get back transport/protocol objects for the subprocess stdin & stdout, though, you won't need to keep around your own coroutine doing the recv() -- you can let the asyncio event loop do this and call data_received() whenever there's new data, and you can then pass that along to the AsyncSSH protocol object's data_received() call. Similarly, any call to write() on the transport you return can be directly turned into a write() on the subprocess's transport (and the same for all the other transport and protocol methods).

[ronf]

Thinking about this a bit more over the last couple of days, it occurred to me that you might not want to spawn an actual subprocess here with pipes for stdin/stdout. If the code you want to run as your proxy is in Python and async-friendly, there'd be no need to pay the overhead for a separate process and the associated pipes. Instead, you can return a (transport, protocol) pair that directly does I/O over whatever channel you wanted to carry the SSH connection over. The aiosocks code is an excellent example of that, if you wanted something to start from. You could just replace the socks protocol classes with your own proxy class, but follow a similar style of feeding data between that proxy connection and an (app_protocol, app_transport) pair you return which gets used by AsyncSSH.

[isidentical]

Thanks, @ronf for the detailed explanation! I'm only adding this functionality to support the ProxyCommand directive in the user's ssh config, and that might be anything so I'll go with subprocesses for this.

[isidentical]

@ronf Is there a specific reason why ProxyCommand is not parsed like other options? I know that the client doesn't support it, though it would be nice for downstream users (like me) to actually have it parsed so that we could implement our own infrastructure for it. Currently, I use a workaround like this;

class SSHFSClientConfig(SSHClientConfig):
    _handlers = {
        'proxycommand': ('ProxyCommand', SSHClientConfig._set_string_list),
        **SSHClientConfig._handlers
    }
    _percent_expand = {
        'ProxyCommand', *SSHClientConfig._percent_expand
    }

though manipulating a bunch of private vars doesn't seem nice :(

[ronf]

I got a chance to look at this more closely today, and it was actually pretty straightforward to implement on top of the low-level asyncio subprocess_exec(). Some minor adaption was needed between the SubprocessTransport and the transport that AsyncSSH was expecting, and similarly for the SubprocessProtocol, but it was only 50 or so lines of code for that. Once that was in place, it was just a matter of hooking up the new config file and connection options to request it, and adding some unit tests.

There were some other minor changes needed to account for the fact that the connection was now a pipe instead of a socket, so things like setsockopt() and getting sockname/peername from it no longer worked, but that was pretty easy to work around.

I also decided to make this available for connect_reverse(), allowing an SSH server to make an outbound connection via ProxyCommand to a client, and once the connection is established allow the client (running listen_reverse()) to make a reverse direction SSH connection over that connection.

This new option also works in get_server_host_key().

All of this should now be available as commit 47375c4 in the "develop" branch. Let me know if you run into any issues with it.

[isidentical]

Oh, this is just amazing. Thank you so much @ronf! I had a draft implementation, though this is clearly much better and well integrated. I'll test it and let you know.

Just wanted to add that it was an absolute pleasure to work with asyncssh so far. I've been implementing a fsspec backend for ssh/sftp called sshfs and after parallel-ssh (didn't fit, for different reasons documented here), I've tried asyncssh and it worked like a charm. It is also much faster than what we have with paramiko right now. Thanks so much for good work you are doing!

[isidentical]

Can confirm it is working for my case on the develop branch! Is there an estimated time for a release including this new feature?

[ronf]

Thanks for the confirmation, and for the kind words -- I'm glad to hear that AsyncSSH is working well for you! Also, that's for additional info about your use case and the pointer to the "fsspec". I hadn't run across that before. At some point, I may take a closer look to see if I should support objects of that type in my SSH process redirection code, similar to the way I added support for aiofiles...

Regarding a release, I'm currently looking into a possible resource leak in some of the unit tests, but once I sort that out I can look at pushing this into "master". If all goes well, I can probably do that this weekend.

[ronf]

This feature is now available in AsyncSSH 2.7.0.