🐛 Strange bug with pasting sudo password via SSH on Linux 🐧 #18597

@binaire-interactif commented on GitHub (Oct 3, 2022):

I'm having the exact same issue with the Windows Terminal Preview (1.16.2642.0) since 2 weeks.

It's intermittent, I have more sucess with the right click, in the shell, right click will paste the correct password, but the not with the sudo prompt.

Same pwd works with remmina from the same WSL2 Ubuntu.

@binaire-interactif commented on GitHub (Oct 3, 2022): I'm having the exact same issue with the Windows Terminal Preview (1.16.2642.0) since 2 weeks. It's intermittent, I have more sucess with the right click, in the shell, right click will paste the correct password, but the not with the sudo prompt. Same pwd works with remmina from the same WSL2 Ubuntu.

claunia commented

@fusenuk commented on GitHub (Oct 6, 2022):

If you paste the password into just the normal prompt, does it appear as you'd expect?

I'm wondering if this is related to an issue I'm seeing with 1.15.2712.0 where the content I'm pasting is randomly being encased with other special formatting.

E.g. in one program, copying the text br256 turns into ^[[200~~br256^[[201~~

This only started happening in the last week or so and doesn't happen with the preview release 1.16.2641.0 (or at least I'm not triggering some big to cause it to happen)

Essentially what I'm getting at is when you paste the copied password, is it inserting extra text unknowingly?

@fusenuk commented on GitHub (Oct 6, 2022): If you paste the password into just the normal prompt, does it appear as you'd expect? I'm wondering if this is related to an issue I'm seeing with 1.15.2712.0 where the content I'm pasting is randomly being encased with other special formatting. E.g. in one program, copying the text br256 turns into ^[[200~br256^[[201~ This only started happening in the last week or so and doesn't happen with the preview release 1.16.2641.0 (or at least I'm not triggering some big to cause it to happen) Essentially what I'm getting at is when you paste the copied password, is it inserting extra text unknowingly?

claunia commented

@KMatuszak commented on GitHub (Oct 6, 2022):

It is not pasting any extra text, the password appears as it should. As I said, pasted password works fine for initial authentication when connecting to the ssh server, but not for authenticating in sudo.

@KMatuszak commented on GitHub (Oct 6, 2022): It is not pasting any extra text, the password appears as it should. As I said, pasted password works fine for initial authentication when connecting to the ssh server, but not for authenticating in sudo.

claunia commented

@zadjii-msft commented on GitHub (Oct 6, 2022):

What keyboard layout are you using? I suspect this is busted logic in the numpad event synthesis logic for that layout. That might explain why it only repros for symbols

@zadjii-msft commented on GitHub (Oct 6, 2022): What keyboard layout are you using? I suspect this is busted logic in the numpad event synthesis logic for that layout. That might explain why it only repros for symbols

claunia commented

@binaire-interactif commented on GitHub (Oct 6, 2022):

What keyboard layout are you using? I suspect this is busted logic in the numpad event synthesis logic for that layout. That might explain why it only repros for symbols

@zadjii-msft I didn't think about that, but that make sense, I'm using the English Canada (US) keyboard.

@binaire-interactif commented on GitHub (Oct 6, 2022): > What keyboard layout are you using? I suspect this is busted logic in the numpad event synthesis logic for that layout. That might explain why it only repros for symbols @zadjii-msft I didn't think about that, but that make sense, I'm using the English Canada (US) keyboard. ![image](https://user-images.githubusercontent.com/2048172/194342935-a8dae25a-4f04-434a-b946-391a51ff20a1.png)

claunia commented

@Gliptal commented on GitHub (Oct 6, 2022):

Same here.

If I press enter and then immediately paste before the attempt fails, the pasted password is encased in escape charachters like @fusenuk said:

I'm using the US International keyboard.

@Gliptal commented on GitHub (Oct 6, 2022): Same here. If I press enter and then immediately paste before the attempt fails, the pasted password is encased in escape charachters like @fusenuk said: ![WindowsTerminal_3RCAH1Ut6f](https://user-images.githubusercontent.com/3907646/194359316-b72dc025-89e1-4b9e-9b26-0be831fbc53f.png) I'm using the US International keyboard.

claunia commented

@KMatuszak commented on GitHub (Oct 6, 2022):

I'm using Polish (Programmers) keyboard layout.

@KMatuszak commented on GitHub (Oct 6, 2022): I'm using `Polish (Programmers)` keyboard layout.

claunia commented

@Gliptal commented on GitHub (Oct 10, 2022):

Any news on this? Either an ETA or some mitigation steps? Windows Terminal is basically useless with ssh in this state.

@Gliptal commented on GitHub (Oct 10, 2022): Any news on this? Either an ETA or some mitigation steps? Windows Terminal is basically useless with ssh in this state.

claunia commented

@j4james commented on GitHub (Oct 11, 2022):

Those of you that are seeing pasted text surrounded by ^[[200~ and ^[[201~, that is because your shell (or perhaps some application or plugin) has enabled bracketed paste mode.

This might be the OP's problem too. When you're attempting to connect to the server, bracketed paste mode assumedly wouldn't be enabled, so you could paste the password without any problem. But if something enables bracketed paste mode after you've logged in, then any future attempt to paste the password could fail. You can probably confirm that by trying to paste into showkey -a since that'll show you any escape sequences surrounding the text.

You can try manually disabling bracketed paste mode by executing printf "\e[?2004l". Although that assumes there isn't something in your shell that is constantly re-enabling that mode.

@j4james commented on GitHub (Oct 11, 2022): Those of you that are seeing pasted text surrounded by `^[[200~` and `^[[201~`, that is because your shell (or perhaps some application or plugin) has enabled [bracketed paste mode](https://en.wikipedia.org/wiki/Bracketed-paste). This _might_ be the OP's problem too. When you're attempting to connect to the server, bracketed paste mode assumedly wouldn't be enabled, so you could paste the password without any problem. But if something enables bracketed paste mode _after_ you've logged in, then any future attempt to paste the password could fail. You can probably confirm that by trying to paste into `showkey -a` since that'll show you any escape sequences surrounding the text. You can try manually disabling bracketed paste mode by executing `printf "\e[?2004l"`. Although that assumes there isn't something in your shell that is constantly re-enabling that mode.

claunia commented

@Gliptal commented on GitHub (Oct 12, 2022):

Those of you that are seeing pasted text surrounded by ^[[200~ and ^[[201~, that is because your shell (or perhaps some application or plugin) has enabled bracketed paste mode.

This might be the OP's problem too. When you're attempting to connect to the server, bracketed paste mode assumedly wouldn't be enabled, so you could paste the password without any problem. But if something enables bracketed paste mode after you've logged in, then any future attempt to paste the password could fail. You can probably confirm that by trying to paste into showkey -a since that'll show you any escape sequences surrounding the text.

You can try manually disabling bracketed paste mode by executing printf "\e[?2004l". Although that assumes there isn't something in your shell that is constantly re-enabling that mode.

Disabling bracketed paste does solve the issue, at least for the current ssh session. I wonder why I never had this problem before with Windows Terminal.

@Gliptal commented on GitHub (Oct 12, 2022): > Those of you that are seeing pasted text surrounded by `^[[200~` and `^[[201~`, that is because your shell (or perhaps some application or plugin) has enabled [bracketed paste mode](https://en.wikipedia.org/wiki/Bracketed-paste). > > This _might_ be the OP's problem too. When you're attempting to connect to the server, bracketed paste mode assumedly wouldn't be enabled, so you could paste the password without any problem. But if something enables bracketed paste mode _after_ you've logged in, then any future attempt to paste the password could fail. You can probably confirm that by trying to paste into `showkey -a` since that'll show you any escape sequences surrounding the text. > > You can try manually disabling bracketed paste mode by executing `printf "\e[?2004l"`. Although that assumes there isn't something in your shell that is constantly re-enabling that mode. Disabling bracketed paste does solve the issue, at least for the current ssh session. I wonder why I never had this problem before with Windows Terminal.

claunia commented

@j4james commented on GitHub (Oct 12, 2022):

@Gliptal I don't know much about Linux, so I'm not speaking with any authority here, but I've been doing some reading, and it appears that Bash and the GNU Readline library have recently (in the last year or two) enabled bracketed paste mode by default (see here).

So my theory is that maybe your home system has recently got the new Bash or Readline that enables bracketed paste (and thus is perfectly capable of parsing pasted strings with the bracketing escape sequences). However, the system that you ssh into may still have an older version of Readline, so it isn't expecting those bracketed escape sequences, and doesn't know to strip them.

If that's the case, the solution may just be to disable bracketed paste mode on your home system. Otherwise it's possible you could also fix the issue by enabling it on the remote system (assuming it's already supported there but just not enabled by default).

@j4james commented on GitHub (Oct 12, 2022): @Gliptal I don't know much about Linux, so I'm not speaking with any authority here, but I've been doing some reading, and it appears that Bash and the GNU Readline library have recently (in the last year or two) enabled bracketed paste mode by default (see [here](https://utcc.utoronto.ca/~cks/space/blog/unix/BashBracketedPasteChange)). So my theory is that maybe your home system has recently got the new Bash or Readline that enables bracketed paste (and thus is perfectly capable of parsing pasted strings with the bracketing escape sequences). However, the system that you ssh into may still have an older version of Readline, so it isn't expecting those bracketed escape sequences, and doesn't know to strip them. If that's the case, the solution may just be to disable bracketed paste mode on your home system. Otherwise it's possible you could also fix the issue by enabling it on the remote system (assuming it's already supported there but just not enabled by default).

claunia commented

@binaire-interactif commented on GitHub (Oct 17, 2022):

@j4james

You can try manually disabling bracketed paste mode by executing printf "\e[?2004l". Although that assumes there isn't something in your shell that is constantly re-enabling that mode.

Thanks, it seem to work on my side, I tried the bind method for the current session and it didn't work. (bind 'set enable-bracketed-paste off')

But adding this set enable-bracketed-paste off to my $HOME/.inputrc and then closing and re-opening a new terminal worked.. 👍👍

@binaire-interactif commented on GitHub (Oct 17, 2022): @j4james > You can try manually disabling bracketed paste mode by executing `printf "\e[?2004l"`. Although that assumes there isn't something in your shell that is constantly re-enabling that mode. Thanks, it seem to work on my side, I tried the bind method for the current session and it didn't work. (`bind 'set enable-bracketed-paste off'`) But adding this `set enable-bracketed-paste off` to my `$HOME/.inputrc` and then closing and re-opening a new terminal worked.. 👍👍

claunia commented

@zadjii-msft commented on GitHub (Oct 21, 2022):

Moving some notes:

In this particular case I might be able to help with one fact: The host I'm seeing this issue on (the Brocade ICX6610 switch) hasn't had a firmware update for years. It did not used to default to bracketed paste, but now it seems to. I would suggest this is something that has just changed recently (i.e. in the last few months) in either WT, PSReadLine or OpenSSH?

Edit: Further to that, it still works without defaulting to bracketed paste once SSH'd in, if I connect via Putty rather than WT.

@SteveL-MSFT, did y'all recently light up bracketed paste support or somesuch? If so... is it being turned off before process launch? We're seeing an increase in reports of an issue where it's on in places where it shouldn't be.

(Just spitballing, nothing conclusive yet)

@zadjii-msft commented on GitHub (Oct 21, 2022): Moving some notes: > In this particular case I might be able to help with one fact: The host I'm seeing this issue on (the Brocade ICX6610 switch) hasn't had a firmware update for years. It did not used to default to bracketed paste, but now it seems to. I would suggest this is something that has just changed recently (i.e. in the last few months) in either WT, PSReadLine or OpenSSH? > > Edit: Further to that, it still works without defaulting to bracketed paste once SSH'd in, if I connect via Putty rather than WT. > @SteveL-MSFT, did y'all recently light up bracketed paste support or somesuch? If so... is it being turned off before process launch? We're seeing an increase in reports of an issue where it's on in places where it shouldn't be. > > (Just spitballing, nothing conclusive yet)

claunia commented

@binaire-interactif commented on GitHub (Oct 21, 2022):

@j4james and everyone else..
Something strange is still going on. the set enable-bracketed-paste off to my $HOME/.inputrc seem to work only in the first instance of my terminal, If I open a new instance as a tab in the terminal then the problem is back! this makes no sense at all.

This bug is so weird...

@binaire-interactif commented on GitHub (Oct 21, 2022): @j4james and everyone else.. Something strange is still going on. the `set enable-bracketed-paste off` to my `$HOME/.inputrc` seem to work only in the first instance of my terminal, If I open a new instance as a tab in the terminal then the problem is back! this makes no sense at all. This bug is so weird...

claunia commented

@DHowett commented on GitHub (Oct 21, 2022):

Could one (or many!) of you share a repro with the debug tap enabled + script running? Please note that this will capture any data you type or paste into Terminal including passwords and any data that comes back out of the application.

Enable the terminal debug tap and launch a terminal with it open.
- This will capture all I/O from the Terminal side into a split pane.
In bash, run script
- This will capture all I/O from the client application side into a file named typescript.
Reproduce the issue
exit from inside bash-inside-script
Share the typescript file and the backlog from the split debugging pane, either here or via private e-mail to the address on my GitHub profile

This may help us in pinning down exactly where in the stack the issue is.

Thanks!

@DHowett commented on GitHub (Oct 21, 2022): Could one (or many!) of you share a repro with the debug tap enabled + `script` running? _Please note that this will capture any data you type or paste into Terminal **including passwords** and any data that comes back out of the application._ 1. Enable the [terminal debug tap](https://github.com/microsoft/terminal/wiki/Enabling-the-debug-tap) and launch a terminal with it open. * This will capture all I/O from the Terminal side into a split pane. 3. In bash, run `script` * This will capture all I/O from the client application side into a file named `typescript`. 4. Reproduce the issue 5. `exit` from inside bash-inside-script 6. Share the `typescript` file and the backlog from the split debugging pane, either here or via private e-mail to the address on my GitHub profile This _may_ help us in pinning down exactly where in the stack the issue is. Thanks!

claunia commented

@fusenuk commented on GitHub (Oct 21, 2022):

Since my initial comment I've only experienced this maybe twice since, with daily 9-5 use of Terminal across multiple remote SSH servers.

Using the command someone had posted previously to turn off bracket mode manually with the printf command did work for me.

I haven't figured out what the pattern is to trigger this, which makes it near impossible to reproduce on command unfortunately.

@fusenuk commented on GitHub (Oct 21, 2022): Since my initial comment I've only experienced this maybe twice since, with daily 9-5 use of Terminal across multiple remote SSH servers. Using the command someone had posted previously to turn off bracket mode manually with the printf command did work for me. I haven't figured out what the pattern is to trigger this, which makes it near impossible to reproduce on command unfortunately.

claunia commented

@j4james commented on GitHub (Oct 21, 2022):

For those of you that are getting this problem intermittently, it may be because you've run some application that has re-enabled bracketed paste mode. More specifically, I've seen reports of this issue with the Midnight Commander editor mcedit. If that's your problem (i.e. you're using mcedit), there's a stackoverflow answer with a hack for working around the issue. That's from several years ago, though, so I'm not certain it still applies.

@j4james commented on GitHub (Oct 21, 2022): For those of you that are getting this problem intermittently, it may be because you've run some application that has re-enabled bracketed paste mode. More specifically, I've seen reports of this issue with the _Midnight Commander_ editor `mcedit`. If that's your problem (i.e. you're using `mcedit`), there's a [stackoverflow answer](https://stackoverflow.com/a/50653674) with a hack for working around the issue. That's from several years ago, though, so I'm not certain it still applies.

claunia commented

@zadjii-msft commented on GitHub (Nov 4, 2022):

Were we the murderer? wsl showkey -a run from a CMD tab, or a pwsh tab, with a Ubuntu-18.04 default distro all get bracketed paste sequences. Hmm.

@zadjii-msft commented on GitHub (Nov 4, 2022): Were _we_ the murderer? `wsl showkey -a` run from a CMD tab, or a pwsh tab, with a Ubuntu-18.04 default distro _all_ get bracketed paste sequences. Hmm.

claunia commented

@zadjii-msft commented on GitHub (Nov 4, 2022):

bad original assumption

Hmmm

diff --git a/src/terminal/adapter/adaptDispatch.cpp b/src/terminal/adapter/adaptDispatch.cpp
index 549d4b3f3..400096db0 100644
--- a/src/terminal/adapter/adaptDispatch.cpp
+++ b/src/terminal/adapter/adaptDispatch.cpp
@@ -978,23 +978,7 @@ bool AdaptDispatch::_SetInputMode(const TerminalInput::Mode mode, const bool ena
     // impact on the actual connected terminal. We can't remove this check,
     // because SSH <=7.7 is out in the wild on all versions of Windows <=2004.

-    // GH#12799 - If the app requested that we disable focus events, DON'T pass
-    // that through. ConPTY would _always_ like to know about focus events.
-
-    return !_api.IsConsolePty() ||
-           !_api.IsVtInputEnabled() ||
-           (!enable && mode == TerminalInput::Mode::FocusEvent);
-
-    // Another way of writing the above statement is:
-    //
-    // const bool inConpty = _api.IsConsolePty();
-    // const bool shouldPassthrough = inConpty && _api.IsVtInputEnabled();
-    // const bool disabledFocusEvents = inConpty && (!enable && mode == TerminalInput::Mode::FocusEvent);
-    // return !shouldPassthrough || disabledFocusEvents;
-    //
-    // It's like a "filter" left to right. Due to the early return via
-    // !IsConsolePty, once you're at the !enable part, IsConsolePty can only be
-    // true anymore.
+    return !_api.IsConsolePty() || !_api.IsVtInputEnabled();
 }

GUYS WHAT

Uh, why are these variables not 0-initialized anymore?

@zadjii-msft commented on GitHub (Nov 4, 2022): <details> <summary>bad original assumption</summary> Hmmm ```diff diff --git a/src/terminal/adapter/adaptDispatch.cpp b/src/terminal/adapter/adaptDispatch.cpp index 549d4b3f3..400096db0 100644 --- a/src/terminal/adapter/adaptDispatch.cpp +++ b/src/terminal/adapter/adaptDispatch.cpp @@ -978,23 +978,7 @@ bool AdaptDispatch::_SetInputMode(const TerminalInput::Mode mode, const bool ena // impact on the actual connected terminal. We can't remove this check, // because SSH <=7.7 is out in the wild on all versions of Windows <=2004. - // GH#12799 - If the app requested that we disable focus events, DON'T pass - // that through. ConPTY would _always_ like to know about focus events. - - return !_api.IsConsolePty() || - !_api.IsVtInputEnabled() || - (!enable && mode == TerminalInput::Mode::FocusEvent); - - // Another way of writing the above statement is: - // - // const bool inConpty = _api.IsConsolePty(); - // const bool shouldPassthrough = inConpty && _api.IsVtInputEnabled(); - // const bool disabledFocusEvents = inConpty && (!enable && mode == TerminalInput::Mode::FocusEvent); - // return !shouldPassthrough || disabledFocusEvents; - // - // It's like a "filter" left to right. Due to the early return via - // !IsConsolePty, once you're at the !enable part, IsConsolePty can only be - // true anymore. + return !_api.IsConsolePty() || !_api.IsVtInputEnabled(); } ``` </details> **GUYS WHAT** ![image](https://user-images.githubusercontent.com/18356694/200078097-d350c072-99ad-4d57-8dac-26df646da07d.png) Uh, why are these variables not 0-initialized anymore?

claunia commented

@lhecker commented on GitHub (Nov 4, 2022):

You're using a debug build right? It uses the debug allocator that sets these fields to 0xCD to indicate uninitialized memory. These fields were never initialized since their introduction which might help explain various bugs, as their initial value in Release builds is then entirely random/undefined. Nice find!

@lhecker commented on GitHub (Nov 4, 2022): You're using a debug build right? It uses the debug allocator that sets these fields to 0xCD to indicate uninitialized memory. These fields were never initialized since their introduction which might help explain various bugs, as their initial value in Release builds is then entirely random/undefined. Nice find!

claunia commented

@j4james commented on GitHub (Nov 4, 2022):

Yikes, apologies to all the innocent shells I was assuming were to blame for this. Maybe this is a good time to move towards initializing everything in the class header, which I think might help avoid issues like this (see CPPCoreGuidelines).

@j4james commented on GitHub (Nov 4, 2022): Yikes, apologies to all the innocent shells I was assuming were to blame for this. Maybe this is a good time to move towards initializing everything in the class header, which I think might help avoid issues like this (see [CPPCoreGuidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c45-dont-define-a-default-constructor-that-only-initializes-data-members-use-in-class-member-initializers-instead)).

claunia commented