Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Unable to establish remote connection automatically from Windows client to Windows server #1358

Closed
tukotech opened this issue Nov 30, 2021 · 4 comments
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. Windows Issue applies to Microsoft Windows

Comments

@tukotech
Copy link

tukotech commented Nov 30, 2021

What Operating System(s) are you seeing this problem on?

Windows

WezTerm version

20210814-124438-54e29167

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

When trying to connect to a remote Windows wezterm ssh session from Windows wezterm client it does not work

To Reproduce

  • On Windows client (Microsoft Windows [Version 10.0.18363.1916]) download zip file.
  • On the other Windows machine (Microsoft Windows [Version 10.0.19043.928]) do:
    • Install SSH server
    • Install wezterm using chocolatey
  • Use the following for wezterm.lua. Save it to the same location where the executables are located
return {
  unix_domains = {
    {
      name = "unix",
      connect_automatically = true,
    }
  },
  keys = {
    {key="x", mods="CTRL|CMD", action="QuitApplication"},
  },
  ssh_domains = {
    {
      name = "my.server",
      remote_address = "192.168.2.17",
      username = "u1",
    },
  }
}
  • Connect to the server, like
    wezterm connect my.server

Configuration

return {
  unix_domains = {
    {
      name = "unix",
      connect_automatically = true,
    }
  },
  keys = {
    {key="x", mods="CTRL|CMD", action="QuitApplication"},
  },
  ssh_domains = {
    {
      name = "my.server",
      remote_address = "192.168.2.17",
      username = "u1",
    },
  }
}

Expected Behavior

Able to automatically connect to the remote machine using ssh.

Logs

2021-11-30T03:09:11.069Z INFO  wezterm_ssh::auth > pubkey_file immediately ok for C:\Users\userx/.ssh/id_rsa
 2021-11-30T03:09:11.069Z ERROR wezterm_client::client > going to run wezterm cli proxy
 2021-11-30T03:09:11.071Z INFO  wezterm_gui::termwindow > OpenGL initialized! ANGLE (Intel(R) UHD Graphics 620 Direct3D11 vs_5_0 ps_5_0) OpenGL ES 3.0.0 (ANGLE 2.1.1 git hash: 07ea804e6201) is_context_loss_possible=true wezterm version: 20210814-124438-54e29167
 2021-11-30T03:09:11.994Z ERROR wezterm_client::client  > ssh stderr:  2021-11-30T03:09:11.998Z WARN  wezterm_client::client > While connecting to C:\Users\u1\.local/share/wezterm\sock: No connection could be made because the target machine actively refused it. (os error 10061).  Will try spawning the server.

 2021-11-30T03:09:12.288Z ERROR wezterm_client::client  > ssh stderr:  2021-11-30T03:09:12.292Z INFO  wezterm_mux_server_impl::local > setting up C:\Users\u1\.local/share/wezterm\sock

 2021-11-30T03:09:12.312Z ERROR wezterm_client::client  > got serial 105 without a corresponding promise
 2021-11-30T03:09:12.465Z ERROR wezterm_client::client  > ssh stderr:  2021-11-30T03:09:12.468Z ERROR wezterm_mux_server_impl::local > decoding a PDU: reading PDU length: EOF while reading leb128 encoded value

Anything else?

If I start mux manually on the remote machine, like wezterm-mux-server.exe --daemonize, it works. It seems like it is a Windows policy issue but I can't point one out.

Additional info:

  • Windows Firewall Disabled
  • UAC disabled, so running cmd.exe is elevated all the time
@tukotech tukotech added the bug Something isn't working label Nov 30, 2021
@tukotech
Copy link
Author

Note that the nightly build is even worse - it just silently fails.

@wez
Copy link
Member

wez commented Nov 30, 2021

The key part of the output is:

2021-11-30T03:09:12.312Z ERROR wezterm_client::client > got serial 105 without a corresponding promise

which makes me think that there might be a Windows-specific race condition to track down

@wez wez added the Windows Issue applies to Microsoft Windows label Nov 30, 2021
wez added a commit that referenced this issue Dec 5, 2021
In some cases, the `wezterm cli proxy` subcommand had terminated
with error, but the client was still happily waiting for more data
to read.

This commit spawns a thread to detect the process termination and
then drop the child struct when it completes; that in turn causes
the stdio descriptors to close and then things tick over.

refs: #1358
wez added a commit that referenced this issue Dec 5, 2021
wez added a commit that referenced this issue Dec 5, 2021
This got lost somewhere along the way.

Importantly, we need to explicitly set the pty to use invalid stdio
handles for the spawned child in order to avoid a weird situation
where eg: cmd or powershell would end up writing to the log file
despite it being spawned into its own PTY.

refs: #1358
@wez wez added the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Dec 5, 2021
@wez
Copy link
Member

wez commented Dec 5, 2021

I think this is fixed now; give it about 45 minutes and try the nightly download and let me know how it goes

@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2023

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 4, 2023
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. Windows Issue applies to Microsoft Windows
Projects
None yet
Development

No branches or pull requests

2 participants