Conhost/ConPTY as used by Win32 Open-SSH inserts/modifies ANSI escape codes (specifically testing bolded text)

[bavis-m]

Environment

Windows build number: 10.0.19041.746
Windows Terminal version (if applicable): Preview v1.5.3242.0\

The Problem

My color scheme in Windows Terminal has default black text, and the default foreground bold color (<ESC>[1m) comes out dark grey. I'm assuming this is due to Windows Terminal using bright colors since we have no actual bold font support.

The default foreground bold color fails to work correctly when ssh-ing into a machine running the windows OpenSSH server (as installed from the Optional Features settings page). It comes out as bright white (color 97 for 256 color supporting terminals). It doesn't appear to matter what the shell on the other end is, I've tested this using both bash.exe as the shell, or the default cmd.exe. All that matters is that sshd allocates a pty.

Steps to reproduce

On a machine running Win32 OpenSSH server, make a script that outputs some default fg color bolded text.

For instance, if bash.exe is your shell, test.sh with contents:

#! /usr/bin/env bash
echo -e "\e[1m Bold Text \e[m"

If cmd.exe is you shell, try test.bat:

forfiles /m some_file_in_your_default_folder /c "cmd /c echo 0x1B[1m Bold Text 0x1B[m"

Then, ssh into that machine from a terminal (note this works with either Windows Terminal, or the default conhost.exe terminal, and it doesn't matter what your local shell is, WSL or cmd.exe) and run the command. It is helpful if you are in a color scheme that has a white background and a dark foreground color.

ssh user@targetmachine test.sh will write Bold Text to the terminal with correct ("light black") colors.

ssh -t user@targetmachine test.sh will write Bold Text to the terminal in bright white text. This is easily visible by showing the control codes themselves:

ssh -t user@targetmachine test.sh | sed 's/\x1b/\\e/g' Will show something like: \e[2J\e[m\e[H\e]0;C:\WINDOWS\system32\conhost.exe\e[?25h\e[1m\e[97m Bold Text \e[m

You can clearly see, along with sending an additional code to set the terminal title string, it changes <ESC>[1m to <ESC>[1m<ESC>[97m

Expected behavior

conhost.exe leaves my terminal control codes well enough alone.

I'm not sure if this is the right place for this, if conhost.exe is doing this, or if I'm even understanding/diagnosing the problem 100% correctly. I'll also crosspost this to PowerShell/Win32-OpenSSH on github.

NOTE: I do not see this incorrect behaviour if I ssh into sshd running as a service in WSL, i.e. apt get openssh-server && service sshd start.

[DHowett]

So! This is definitely the right place. I’ve got good news and bad news.

This was one of our most annoying subtle bugs (in my opinion), which we tracked with #2661. There’s a heck of a lot of technical detail on why it existed and how it was fixed over there.

Good news: it’s fixed.

Bad news: the version of conpty OpenSSH uses is tied to the version of Windows on the server. Unfortunately, we can’t service that one. 😦

Thanks for writing up such a comprehensive report. Sorry to dupe it.

/dup #2661

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

[DHowett]

(That issue bugged me so much that even as our issue tracker is approaching 9,000 total issues I still remember it by number 😄)

[bavis-m]

Thanks for the response. I don't think I ever would have come up with the right search terms to find that issue on my own, so I appreciate the link. Is the real fix to wait until a windows update comes down the line that pulls this in to the packaged conhost? Will me being on an insider ring affect that time? Would #1817 help at all with this in the meantime?

[DHowett]

Insider builds are closer to our development branches, and I believe the current one does have the fix. :)

re 1817: no warranty expressed/implied but it should work and I can’t officially support it if it doesn’t 😉

[bavis-m]

It appears like the beta track (on windows build 19042.782 and conhost.exe version 10.0.19041.746, same as the non-insider track windows version) still exhibits the problem, and I don't have any machines on the dev track, so maybe I'll give 1817 a try (but you didn't hear that...). Thanks again for your help, I'll stop spamming this issue now.