openssh-rust
Unable to establish connection on Windows 11
Using version 0.8.1, creating a connection does not seem to work when on Winodws 11.
When executing the following line of code:
let session = Session::connect(format!("root@{}", SERVER_IP.to_string()), KnownHosts::Accept).await?;
I either get the following output, no folder in root of my project and the process terminates:
Error: Connect(Custom { kind: ConnectionAborted, error: "getsockname failed: Bad file descriptor\r\nssh_dispatch_run_fatal: Connection to UNKNOWN port -1: unexpected internal error" })
Or I do not get any output and the process "hangs" at this line. The library then created a folder in the root of my project named ".ssh-connection***" before waiting indefinitely.
This crate is basically UNIX-only, since it relies on the OpenSSH toolchain, which is primarily a UNIX tool. It is possible to get it working with Windows, but it's not something we've been focused on. If you want to take on trying to fix it up for Windows though I'd be happy to look at a PR!
Also https://github.com/microsoft/vscode-remote-release/issues/96 for control master on windows
@inf0rm4tik3r You can compile and run this crate in WSL (Windows Subsystem for Linux), it will work just fine.
I think we can modify the process-impl to connect directly instead of using the control master, which just doesn't work on windows.
Oof, them not supporting a control master is pretty unfortunate. But yes, I agree, we could support Windows by having it just have each ssh command connect separately, though this would need to be very well documented.
#61 is closed due to adding too much complexity, forcing user to depend on process-mux implementation, which might be removed in the future and lacking way to test it.
@jonhoo Perhaps we can support windows by creating a separate crate for it, that server as a simple wrapper for launching ssh on windows, without any control multiplex support?
This would make the code more maintainable than merging it into this crate and also make it clearer to the user, and then maybe we can find a way to test it in the CI.
... forcing user to depend on
process-muximplementation, which might be removed in the future and lacking way to test it.
What does this mean? I am a new user of this crate. Does this mean that I should be using Session::connect_mux over Session::connect?
Also, does pushing for native-mux over process-mux mean giving up on Windows support? I have no idea how any of this works, but I would've assumed that relying on the ssh command (also available on Windows) would have made it easier at some point to find a way of supporting Windows as well.
What does this mean? I am a new user of this crate. Does this mean that I should be using Session::connect_mux over Session::connect?
Yes, it native-mux provides better errors, better performance and less memory usage.
Also, does pushing for native-mux over process-mux mean giving up on Windows support? I have no idea how any of this works, but I would've assumed that relying on the ssh command (also available on Windows) would have made it easier at some point to find a way of supporting Windows as well.
No, the process-mux implementation does not work on Windows.
In this crate, we use ssh multiplexing feature of openssh, which unfortunately does not work on windows due to its support of Unix Socket being incomplete.
I am working on another crate openssh-generic, which does not use multiplexing and should work on all platforms.
The downside however, is longer startup time and it uses more resource.
I am planning on supporting windows in openssh-mux-client https://github.com/openssh-rust/openssh-mux-client/issues/6 and I have abandoned the effort to create openssh-generic, since it is mostly pre-0.9 code that wraps around tokio::process.