starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Microsoft Terminal support for ssh X11-forwarding sessions via WSL-G #17404

New Issue
Closed
opened 2026-01-31 05:41:29 +00:00 by claunia · 3 comments
claunia commented 2026-01-31 05:41:29 +00:00
Owner
Copy Link

Originally created by @elasticdotventures on GitHub (May 5, 2022).

X11 forwarding support for MS Terminal and/or microsoft ssh
This is a feature of other ssh window managers/applications such as putty.

Presently Windows 11, Ubuntu Linux, WSL2 specifically has first class x11 graphics via WSL-G
https://github.com/microsoft/wslg

  • I will be opening a related issue on the microsoft/wslg github and referencing this one.

I give an example X11 command line that works non-determinstically in windows 11 below. For X11 forwarding to work as expected it can only happen after an interactive WSL2 shell has been started. I'm suggesting that WSL-G invocation should be a checkbox or setting in the MS-Terminal, WSL-G should be able to started from within ms-terminal.

WSL-G as it was designed for WSL2 only works with the local instance for X11, but once WSL-G has been started (via WSL-2 interactive shell), then remote systems can be accessed using MS-Terminal microsoft-ssh & the X11 support is functional .. actually to describe it as function is inappropriate, X11 over WSL-G is "first class".

However if the same sessions are started BEFORE WSL2 has started interactively, then sessions have no X11 support. As such ms-terminal only works "as expected" when WSL2 & WSL-g is started first.

So, explaining it again, backwards - In Windows 11, I must first start WSL2 in another session (this is 1x per day, post-reboot toil that I don't need), THEN I wait, THEN I can use this command line below to access a remote (non-local) host with X11 in ms-terminal.

wsl.exe -- ssh -X -Y $hostname

ssh parameter explanation:
-X enables X11 forwarding, (not explicitly needed with -X)
-Y enables X11 trusted forwarding

... also to be clear about wsl.exe:

  • -- tells wsl.exe to ignore remaining parameters,
  • the wsl.exe line in the example above is non-interactive, it does NOT start WSL2 interactively, ergo - no WSL-G
  • WSL-G which isn't started unless I login interactively.
  • But the wsl.exe is required to run ssh inside WSL2 for X11 to work after an interactive login.

$ echo $DISPLAY
... this should display something like localhost:10.0
$ xeyes
... this should start a graphical X11 application xeyes on the host machine if X11 forwarding is working.

Ms-terminal should be able to start WSL-G prior to opening an ssh window that requires X11 support.
ssh window manager is a primary function of the application.

Ms-terminal should be able to ensure WSL-G is running (even a checkbox or settings), or start WSL-G

The result is a non-determinstic behavior experienced when using the ms-terminal application - but not necessarily at the fault of ms-terminal which I think is a great but can use some better X11/WSL-G support.

Originally created by @elasticdotventures on GitHub (May 5, 2022). X11 forwarding support for MS Terminal and/or microsoft ssh This is a feature of other ssh window managers/applications such as putty. Presently Windows 11, Ubuntu Linux, WSL2 specifically has first class x11 graphics via WSL-G https://github.com/microsoft/wslg * I will be opening a related issue on the microsoft/wslg github and referencing this one. I give an example X11 command line that works non-determinstically in windows 11 below. For X11 forwarding to work as expected it can only happen after an interactive WSL2 shell has been started. I'm suggesting that WSL-G invocation should be a checkbox or setting in the MS-Terminal, WSL-G should be able to started from within ms-terminal. WSL-G as it was designed for WSL2 only works with the local instance for X11, but once WSL-G has been started (via WSL-2 interactive shell), then remote systems can be accessed using MS-Terminal microsoft-ssh & the X11 support is functional .. actually to describe it as function is inappropriate, X11 over WSL-G is "first class". However if the same sessions are started BEFORE WSL2 has started interactively, then sessions have no X11 support. As such ms-terminal only works "as expected" when WSL2 & WSL-g is started first. So, explaining it again, backwards - In Windows 11, I must first start WSL2 in another session (this is 1x per day, post-reboot toil that I don't need), THEN I wait, THEN I can use this command line below to access a remote (non-local) host with X11 in ms-terminal. <!-- --- --- --- --- --- --- --- --- --- --- --- --- # Example Remote SSH Command Line (place in ms-terminal "command line" field) --- --- --- --- --- --- --- --- --- --- --- --- --- --> wsl.exe -- ssh -X -Y $hostname ssh parameter explanation: -X enables X11 forwarding, (not explicitly needed with -X) -Y enables X11 trusted forwarding ... also to be clear about wsl.exe: * -- tells wsl.exe to ignore remaining parameters, * the wsl.exe line in the example above is non-interactive, it does NOT start WSL2 interactively, ergo - no WSL-G * WSL-G which isn't started unless I login interactively. * But the wsl.exe is required to run ssh inside WSL2 for X11 to work after an interactive login. <!-- --- --- --- --- --- --- --- --- --- --- --- --- # next on REMOTE $hostname (with working X11) --- --- --- --- --- --- --- --- --- --- --- --- --- --> $ echo $DISPLAY ... this should display something like localhost:10.0 $ xeyes ... this should start a graphical X11 application xeyes on the host machine if X11 forwarding is working. <!-- --- --- --- --- --- --- --- --- --- --- --- --- # Description of the new feature/enhancement --- --- --- --- --- --- --- --- --- --- --- --- --- --> Ms-terminal should be able to start WSL-G prior to opening an ssh window that requires X11 support. ssh window manager is a primary function of the application. <!-- # Proposed technical implementation details (optional) --> Ms-terminal should be able to ensure WSL-G is running (even a checkbox or settings), or start WSL-G <!-- A clear and concise description of what you want to happen. --> The result is a non-determinstic behavior experienced when using the ms-terminal application - but not necessarily at the fault of ms-terminal which I think is a great but can use some better X11/WSL-G support.
claunia added the Issue-FeatureResolution-ExternalNeeds-Tag-Fix labels 2026-01-31 05:41:30 +00:00
claunia commented 2026-01-31 05:41:32 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 5, 2022):

I'm pretty sure this isn't a Terminal issue, it's definitely a WSL issue. We're good friends with the WSL team, sure, but ultimately, they own the user experience of WSL (and WSLg). I'll let them discuss how they'd like to handle this over on their repos.

Thanks!

/dup https://github.com/microsoft/WSL/issues/8367

as an aside - where'd you pick up the "MS Terminal" terminology? I don't think we've ever referred to the Windows Terminal as "ms-terminal", yet there's definitely a subset of folks who use that to refer to the Terminal. I'm mostly just curious where that came from.

@zadjii-msft commented on GitHub (May 5, 2022): I'm pretty sure this isn't a Terminal issue, it's definitely a WSL issue. We're good friends with the WSL team, sure, but ultimately, they own the user experience of WSL (and WSLg). I'll let them discuss how they'd like to handle this over on their repos. Thanks! /dup https://github.com/microsoft/WSL/issues/8367 <hr> _as an aside_ - where'd you pick up the "MS Terminal" terminology? I don't think we've ever referred to the Windows Terminal as "ms-terminal", yet there's definitely a subset of folks who use that to refer to the Terminal. I'm mostly just curious where that came from.
claunia commented 2026-01-31 05:41:32 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 5, 2022):

Hi! We've identified this issue as a duplicate of one that exists on somebody else's Issue Tracker. Please make sure you subscribe to the referenced external issue for future updates. Thanks for your report!

@ghost commented on GitHub (May 5, 2022): Hi! We've identified this issue as a duplicate of one that exists on somebody else's Issue Tracker. Please make sure you subscribe to the referenced external issue for future updates. Thanks for your report!
claunia commented 2026-01-31 05:41:32 +00:00
Author
Owner
Copy Link

@elasticdotventures commented on GitHub (May 10, 2022):

@zadjii-msft re: why I and perhaps others call it "MS Terminal" .. public repo name/url is:

github.com/microsoft/terminal

@elasticdotventures commented on GitHub (May 10, 2022): @zadjii-msft re: why I and perhaps others call it "MS Terminal" .. public repo name/url is: github.com/microsoft/terminal
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Feature Needs-Tag-Fix Resolution-External
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#17404
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?