Support ssh2 transportation to not require distant server binary

[chipsenkbeil]

Looking through ssh2-rs, we may be able to implement all of the current features of distant purely from a mixture of sftp and exec. There are a couple of gotchas that I think should be okay:

1. We have to provide a mode like 644 for file operations (but capable of read/write/append for files over sftp channel)
2. Reading a directory with a depth > 1 will require multiple calls (expensive)
3. Running a proxy for a process is a bit different; I think I use exec and then can read stdout from the channel (see discussion), write stdin to the channel, and read stderr from this
4. Still need to manage a proc list, but it would map to a series of channels, each dedicated to running a singular process
5. System info would probably be unsupported as we're using info baked into our Rust binary instead of reading directly from the syste

Authentication may be the hardest part and there's some good discussion here regarding KeyboardInteractivePrompt and userauth_password.

[chipsenkbeil]

See blog post that uses a little bit of ssh-rs: http://saidvandeklundert.net/learn/2021-08-06-rust-ssh-cli-tool/

It leverages rpassword to read in a password without showing it externally. Although from my reading, the use of userauth_password appears to be misleading as this is typically disabled in favor of userauth_keyboard_interactive to leverage PAM or other auth backends.

Should check out how wezterm-ssh's auth.rs handles this. From reading through it, based on parsing a config, it will try:

• auth agent & pubkey auth if methods include "publickey"
• userauth password if methods include "password" (prompts for it)
• keyboard interactive if methods include "keyboard-interactive"
  • Implements a pty that shows the username and instructions, capturing each line as an answer: https://github.com/wez/wezterm/blob/7deb215303ce1a8e64d48f65ef3e0a1d24fc2fbc/wezterm-ssh/examples/ssh.rs#L86

[chipsenkbeil]

From wezterm-ssh, it pulls in auth methods using ssh2's session.auth_methods and does this continuously in a loop when new methods like 2fac show up later.

[chipsenkbeil]

Session and all channels must be in the same thread: alexcrichton/ssh2-rs#36 (comment)

This means the design would be to use set_blocking(false) to ensure that we can loop through and process incoming and outgoing data. I'm seeing in wezterm-ssh that blocking is enabled for certain operations, so there may be EVEN MORE nuances such at those described in Leaking LIBSSH2_SESSION objects.

As the first attempt, we have a dedicated thread that contains the session and a map of channels. The thread uses message passing to get requests to perform. For each request, we determine if we need to create a new channel (for a process) or use the existing sftp channel (for io).

[chipsenkbeil]

sftp appears to cover everything we need for I/O (including realpath to canonicalize, etc) except for copying files and directories between locations on the remote machine only.

1. We could read directories, get paths, read file contents, and then reconstruct using sftp, but that would be really, REALLY expensive
2. We detect what system we're on and apply either unix cp -R <src> <dst> or windows xcopy <src> <dst> /s /e (doc) over an exec call

[chipsenkbeil]

Went with option 2 above, so we're just trying a cp followed by xcopy if that fails. Doing something similar for killing a process where we try kill -9 <PID> and then taskkill /PID <PID>.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.