-
-
Notifications
You must be signed in to change notification settings - Fork 844
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
cross platform ssh session not working #507
Comments
I think the messaging about the version mismatch is a mis-attributed error. This part of the client side logs:
is normally where the client would launch I wonder if the issue might be that I'd suggest terminating the manually launched |
I started wezterm-mux-server as the client logs seems to suggest I should run something on the host. I was also wanting to capture some logs on host. In the wezterm-mux-server logs given in the issue-description, the last two error lines occurred after the client was started. The wezterm-mux-server was run in a cmd prompt as the same regular user as the wezterm client used to start the wezterm ssh session However, the wezterm ssh fails even when no wezterm or wezterm-mux-server process is started on the host. I checked in windows task-manager.
captured on another run inside the cmd host
note that |
wezterm is installed via scoop |
The wincng based build doesn't recognize newer keys which makes it impossible to connect to a reasonably up to date Fedora installation. This commit points to my branch of ssh2-rs that has some changes to build ssh2 against the vendored openssl that is already part of the dependency graph for wezterm. refs: #507
Could you give the latest nightly build a try? I think the main blocker was 9745a24 but there have been a number of improvements around ssh that I think will help too! |
First checked with the last release (info about nightly in next comment)
|
!! some progress but no success Downloaded got the nightly from https://github.com/wez/wezterm/releases/nightly
Observations
|
Partial success!! if wezterm-mux-server is manually prestarted. The ssh connection from wezterm on linux, succeeds, if on the windows host-pc, I manually pre-start the wezterm-mux-server in a command window (or in a wezterm terminal window with powershell) in windows command prompt
In linux gnome-terminal:
|
This has been a commonly requested feature in the past week, and it's a reasonable one. The mux server inherited the close-when-done behavior from when it used to be an alternate front-end in the same executable as the gui, but it doesn't need to be that way any more. We also need to accomodate that case in the client: if the newly attached domain doesn't result in any panes being imported, we need to spawn a new command there in order to keep the client alive. The pre-existing check for whether the mux was empty had false positives because the local mux may still reference the pane from the connection UI, which would finish closing out shortly after we had decided not to spawn anything, and then the client would close. refs: #631 refs: #507
Would you mind updating both the client and server to the latest nightly and let me know how things work out for you? |
This issue has been automatically closed because there has been no response to the request for more information from the original author. With only the information that is currently in the issue, there isn't enough information to take further action. Please reach out if you have or find the answers we need so that we can investigate further. |
Same wezterm version is installed on both host-windows-10 and guest-fedora-34
Without wezterm mux server prestarted
with wezterm mux-server
As before, the ssh connection succeeds if the wezterm-mux-server is pre-started in a cmd-window on host |
same with
without wezterm-mux-server
with wezterm-mux-server
As before, the ssh connection succeeds if the wezterm-mux-server is pre-started in a cmd-window on host
|
Actually how to ssh domain from Windows 10 to linux ? But how could I launch this command |
When applications are started from command shells, in contrast to start menu launcher shortcuts, You need to set the executable path environment variable for the OS, which is 'Path' for windows, 'PATH' for linux. |
great this works |
@xiangpeng2008 Could you file a separate issue for this? |
I'll try my best to get to it within a couple of days. presently computer in semi-configured state as I juggle disks around, trying to move above from raw partitions to vdisks. I'm also investigating switching from vbox to whpx/qemu. I'll update in this comment when I set things back up. |
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. |
Describe the bug
Cross platform ssh not working
Attempt to do a wezterm initiated ssh session from virtualbox/fedora-33-linux-VM to host/Win10 failing
The same version of wezterm is installed on both linux and windows.
I would argue that small differences in the wezterm version should not matter, and both linux and windows should be able to interpret a terminal-data-stream of either that of linux or that of windows.
ssh-ing from inside the terminal, which does work, should not be too different from a direct wezterm initiated ssh session.
Environment (please complete the following information):
wezterm -V
and include its output hereTo Reproduce
Steps to reproduce the behavior.
wezterm connect host-pc
Configuration
Be sure to include the relevant section(s) of your
wezterm.lua
configuration file.Expected behavior
A clear and concise description of what you expected to happen.
Wezterm ssh from windows to linux should work
Wezterm ssh from linux to windows should work
server side logs
client side logs
The text was updated successfully, but these errors were encountered: