-
Notifications
You must be signed in to change notification settings - Fork 310
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
Feature request: Added option to allow users to specify the remote IP address when forwarding server #10627
Comments
Thank you for the detailed issue. It does indeed seem like we hardcode in the loopdevice device IP for the tunnel. It seems like we'd need a second setting for the Remote OS's interface (10.3.128.1) Is that SSH config all you are doing to force the VS Code server installation into the container? If there's any other configuration you could share for me to get a quick repro, that would be appreciated :) |
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! |
Hello @joshspicer! Thanks for your reply.
"remote.SSH.bindHost": {
"<Your Remote Host>": "<The Ip of Remote Host (not 127.0.0.1)>"
} Expected behavior 1: The tunnel is established normally using the specified interface. (Use the Expected behavior 2: The tunnel is established correctly after we add a setting such as: "remote.SSH.connectHost": {
"<Your Remote Host>": "<The Ip of Remote Host (not 127.0.0.1)>"
} Actual behavior: Still using loop interface and tunnel establishment failed, the logs are as follows: sshd logs:
Remote SSH Logs: details
|
I want to run VS Code Server in the user containers and access the container directly through sshd from a remote host. The sshd configuration of the remote host is as follows:
The network architecture is as follows:
The VS Code Server and sshd are located in two different network namespaces, which prevents them from using the default loopback network interface for communication. I noticed that the Remote SSH extension offers an option called
remote.SSH.bindHost
, allowing users to set the VS Code Server to listen on the other interface, such as the network bridge. However, when VS Code establishes a forwarding tunnel, it connects to 127.0.0.1. I'm curious if this hardcoding is a bug or a related functional option is unavailable.When VS Code establishes a forwarding connection to a remote SSH server, can it connect to
remote.SSH.bindHost
or use a new user option such asremote.SSH.connectHost
?This is the Error log from sshd in Remote OS:
This is the Remote SSH Log during the connection:
Remote SSH Log
The text was updated successfully, but these errors were encountered: