search

PowerShell / Win32-OpenSSH

Win32 port of OpenSSH
7.36k stars 757 forks source link

Strange character sequences (ANSI escape sequences?) leaking into shell prompt when starting/attaching Tmux #2275

Open primeos-work opened 4 days ago

primeos-work commented 4 days ago

Prerequisites

Steps to reproduce

Connect to a Linux/Unix host via ssh and attach to a tmux session. Strangely the results seem to differ based on the target OS, e.g.:

Expected behavior

I can attach to my Tmux session and it looks exactly as I left it. This usually means that the last line of the active Tmux window/pane contains a empty shell prompt like this:

[michael@groot ~]$

Actual behavior

I get some additional random characters ("garbage") behind the prompt, e.g.:

[michael@groot ~]$ 61;6;7;21;22;23;24;28;32;42c

Error details

No response

Environment data

I am using the Windows Terminal and it doesn't matter if I uses the "Windows PowerShell", "Command Prompt", or "Git Bash". When I use "Git Bash" via "Windows Terminal" everything works as expected with /usr/bin/ssh (OpenSSH_9.7p1, OpenSSL 3.2.1 30 Jan 2024) but not with /c/Program\ Files/OpenSSH/ssh (OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2) which is why I came to the conclusion that this seems to be a OpenSSH for Windows bug. The second indication that this seems to be an OpenSSH for Windows bug is that I didn't get those unexpected character sequence with SSH_TERM_CONHOST_PARSER=0 (but that also makes the rendering much much slower and I get significant visual glitches like a green background color (probably due to the status line background color from tmux)).

Anyway, here is the desired output but I don't expect it to be relevant in this case:

Name                           Value
----                           -----
PSVersion                      5.1.19041.4894
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.4894
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Version

OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2

Visuals

No response

primeos-work commented 4 days ago

Please also note that there are already a lot of related issues/reports but not in this repository. I tried the following workarounds/solutions but none of them worked for me:

Some links to the reports that I found:

Other relevant links:

So my conclusions are the following:

yoctozepto commented 3 days ago

On OpenSSH_for_Windows_9.8 Win32-OpenSSH-GitHubp1, LibreSSL 3.8.2 as built from https://github.com/PowerShell/openssh-portable/commit/414d8531cea252ddbd8beba3f6de77597e036ff6 it happens almost every time tmux is run and no workaround helps. But it happens only in Windows Terminal. The legacy command host is not affected so it's most likely an issue of the Windows Terminal. However, it also does not happen with WSL2-based ssh even though it's still in Windows Terminal.

primeos-work commented 2 days ago

Thanks for the additional data @yoctozepto! :)

I think it's the combination of the terminal and OpenSSH for Windows but that the actual bug is in OpenSSH for Windows and the terminal only matters as it will affect the response to tmux's ESC [ c (\033[c) "Request terminal attributes" (if https://serverfault.com/questions/1130064/why-is-the-windows-11-terminal-pushing-escape-sequences-to-tmux is correct).

I did run two additional tests yesterday:

To be sure I did another test today via Ubuntu 24.04 LTS in WSL 2: I installed and started openssh-server in the Ubuntu VM/container, started a Tmux session and then did compare a "direct" terminal with an SSH connection:

PS: I can also trigger the bug with echo instead of tmux like this (or echo -e '\e[c', etc.):

mweiss@groot ~ $ echo -e '\033[c'

mweiss@groot ~ $ 1;2c
yoctozepto commented 2 days ago

OK, so it truly is the Win32-OpenSSH - that is the common denominator here. It needs certain conditions to happen but it does not happen without it.