Support ssh2 transportation to not require distant server binary about distant HOT 6 CLOSED

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

from distant.

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.

from distant.

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).

from distant.

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

from distant.

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>.

from distant.

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.

from distant.