-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Remote-SSH Bug]: Can not log into Cygwin SSH server with bash shell #9992
Comments
We probably have to do something different for a server running cygwin. It looks like there are some checks that we normally have to do for windows remotes which are failing here. |
This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 10 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation. Happy Coding! |
I would love to see this implemented as well. I am using Remote SSH to develop a Windows C++ Desktop application on my remote machine (Windows 10) using CMake and the CMake tools within VS Code and it's not possible to run my GUI application (when I launch it with CMake) from within an SSH connection that is made to the official Windows OpenSSH server. This is because launching it from the CMake panel opens the integrated terminal on the remote machine (via SSH) and executes the built executable by pasting the path to it, but it doesn't run as a GUI application under the user's logged in GUI/Desktop session, so e.g. the window it creates is never visible when I try to test it via VNC. An option would be to start sshd as a user, but that doesn't work anymore with the official Windows OpenSSH server:
https://stackoverflow.com/questions/59880794/starting-gui-programs-via-openssh-on-windows I've tried connecting to the sshd that comes with Git Bash without luck yet: VS Code settings: "remote.SSH.enableRemoteCommand": true,
"remote.SSH.remotePlatform": {
"192.168.122.20": "windows"
},
"remote.SSH.connectTimeout": 60,
"remote.SSH.path": "\"C:\\Program Files\\Git\\usr\\bin\\ssh.exe\"", SSH config:
Also renamed mv $(which uname) $(which uname)-old Otherwise the connection just hangs forever, see #8617. What I am effectively trying to do is to have Remote Development in VS Code via SSH to a remote Windows 10/11 machine, which allows me to execute a GUI application from within that SSH session and see the window it creates pop up in the existing user session (via VNC e.g.) |
This feature request has not yet received the 10 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation. Happy Coding |
🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation. Happy Coding! |
Is there an existing issue for this bug?
Required Troubleshooting Steps
remote.SSH.useLocalServer
settingConnect Locally
It connects successfully
->
No response
Expected Behavior
I would like to connect to a Windows 11 computer running Cygwin SSH. The Cygwin SSH is configured for bash shell which is what I want. I am not sure if the bash shell is relevant for this problem or not.
Steps To Reproduce
I use VSCode Version: 1.90.2 with latest remote SSH extension as of today (v0.112.0). My Windows 11 computer is behind an SSH proxy host. From a standard terminal I can connect via the proxy host directly to the Windows 11 computer Cygwin SSH server. When logging in, a bash shell is offered and I can work from this shell in my development environment.
With the VSCode extension, I do:
CTRL-P
andConnect to host
Remote-SSH Log
Remote-SSH Log
Anything else?
When I set
"remote.SSH.path": "C:\\cygwin64\\bin\\ssh.exe"
then there is an error that the remote ssh would not be executable. So I removed that setting again.When I set
remote.SSH.useLocalServer
tofalse
then the error is slightly different, attached here:Remote-SSH Log
The text was updated successfully, but these errors were encountered: