Host server-10
HostName server-10
IdentityFile C:\\Users\\my.user.name\\.ssh\\id_rsa
ForwardX11 yes
ForwardX11Trusted yes
MobaXterm's main purpose is to enable the use of X11 GUI applications, so it includes a X11 display server. So its SSH client component requests X11 forwarding by default.
VS Code on the other hand does not include an X11 server, and does not request X11 forwarding unless you specifically tell it to do so, by adding the -X, -Y or -XY option in the Enter SSH connection command prompt.
When X11 is forwarded over SSH, the following things happen:
1.) The SSH client connects to the local X11 display server (in Windows typically by making a local TCP connection to port 6000, unless specified otherwise) and verifies it's accessible.
2.) When negotiating a connection with the remote SSH server, the client requests X11 forwarding. If the remote SSH server accepts the request, it will set up a local X11 proxy listening for local connections on port 6010 or the first free port after that. It will set the DISPLAY environment variable on the remote end, typically to localhost:<X11 proxy port number - 6000>. It will also provision a ~/.Xauthority file with a dummy MIT-MAGIC-COOKIE session key.
3.) When a remote X11 application starts, it will see the DISPLAY environment variable and the ~/.Xauthority file, and as instructed by them, will establish a X11 connection to the proxy created by the remote SSH server.
4.) The proxy port will accept X11 connections (normally within the same host only), verify the session key, and pass the X11 traffic within the encrypted SSH tunnel to the local SSH client.
5.) The local SSH client will replace the remote dummy cookie with one required by the actual local X11 server (if necessary) and forward the traffic locally to the X11 display server. Any responses will be sent back the same way.
The remote X11 port number and the corresponding DISPLAY variable value depends on how many other existing SSH-forwarded X11 connections (and possible other users of TCP ports in the 6010+ range) there are on the remote server. So, hardcoding the DISPLAY variable is indeed not a good idea.
The X410 X11 server for Windows has a cookbook with pictures for setting up X11 connections with VS Code: https://x410.dev/cookbook/enabling-ssh-x11-forwarding-in-visual-studio-code-for-remote-development/
You can use any Windows X11 display server, but the principle will be the same.
If your local X11 display server accepts direct remote X11 connections in port 6000/TCP, then you technically could set the remote DISPLAY variable manually to <IP or hostname of the local system>:0. However, you should not do this unless you absolutely trust anyone that will be able to connect to your local system: this sets up an unencrypted X11 connection, which can be easily eavesdropped.
A malicious remote X11 connection can also act as a keylogger for your entire local display, so you should not allow applications that are not legitimate parts of your own session to connect to your X11 display server. The X11 session cookie mechanism is designed to prevent that: unless the remote application can produce the session-specific cookie provisioned to your user account only, the X11 connection will be dropped.
Practically all Linux distributions I've seen since the year 2000 have long since configured their X11 servers to reject any unencrypted remote X11 connections by default, but Windows X11 servers might not have done so.
–
–
