Win32-OpenSSH

Win32-OpenSSH copied to clipboard

Troubleshooting steps Checked..

Terminal issue? please go through wiki Checked.

"OpenSSH for Windows" version 8.1.0.0

Server OperatingSystem Windows Server 2019 Standard en_windows_server_2019_updated_june_2020_x64 en_windows_server_2019_updated_march_2020_x64

Client OperatingSystem CentOS 6.10: $ ssh -V OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013

CentOS 7.8: $ /usr/bin/ssh -V OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017

CentOs 8.1 $ /usr/bin/ssh -V OpenSSH_8.0p1, OpenSSL 1.1.1c FIPS 28 May 2019

What is failing We are maintaining the same sshd config on both Windows 2016 and Windows 2019. When linux ssh clients attach to a Windows 2016 server we get no repeating non-printing character spam, but on Windows 2019 we get an endless amount of "^[[153X^[[153C^M" Where "153" is the column size of the xterm.
This makes thing difficult for expect scripts and does not occur on Windows 2016.

For example:

$ script Script started, file is typescript $ ssh administrator@chug09 administrator@chug09's password: Microsoft Windows [Version 10.0.17763.1282] (c) 2018 Microsoft Corporation. All rights reserved.

CHUG09# exit Connection to chug09 closed. $ exit exit Script done, file is typescript

---

The contents of the typescript file:

Script started on Mon 06 Jul 2020 05:41:27 PM PDT $ ssh administrator@chug09^M administrator@chug09's password: ^M ^[[2J^[[?25l^[[m^[[H^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^[[H^[]0;c:\windows\system32\cmd.exe^@^G^[[?25h^[[?25lMicrosoft Windows [Version 10.0.17763.1282]^[[110X^[[110C^M (c) 2018 Microsoft Corporation. All rights reserved.^[[101X^[[101C^M ^[[153X^[[153C^M CHUG09#^[[146X^[[146C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ^[[153X^[[153C^M ... ... ...

I know, I know...I likely need to report this to Microsoft, but thought you all might have some insight. Thanks.

@DHowett - Is this a known issue?

@github-dub - Please provide the output of windows version that looks like this

Microsoft Windows [Version 10.0.17763.1282]

This should only be happening if the SSH server is allocating a pty. It should not be allocating a pty unless -t is passed to the ssh client.

Output like this indicates that the SSH server is expecting an interactive session instead of a non-interactive one. expect would probably prefer a non-interactive session.

@DHowett - By default SSH server allocates pty session. no-pty is allocated only if the SSH client uses -T (capital letter). Is there a known bug with the pty session on windows server 2019?

@bagajjal this is not a PTY issue. The default behavior of ssh on non-Windows platforms is to only allocate a tty if the user is in an interactive session (where ssh's standard output handle is connected to a tty.)

If Win32-OpenSSH is allocating a tty when the output handle is not connected to a tty, it is acting in a way that is different from normal ssh.

The manual for ssh says:

 If an interactive session is requested ssh by default will only request a pseudo-terminal (pty) for interactive
 sessions when the client has one.  The flags -T and -t can be used to override this behaviour.

 If a pseudo-terminal has been allocated the user may use the escape characters noted below.

 If no pseudo-terminal has been allocated, the session is transparent and can be used to reliably transfer binary
 data.  On most systems, setting the escape character to “none” will also make the session transparent even if a
 tty is used.

If this was working before the upgrade and the switch to PTY mode, it was working simply by luck.

@DHowett - As per description, the problem is occurring in the interactive ssh session.

This makes thing difficult for expect scripts and does not occur on Windows 2016.

This does not imply an interactive session. expect is typically used to drive programs non-interactively.

We will need to wait for @github-dub to clarify whether their intended use is interactive or via piping ssh to another process or driving it without interactive use.

Right, we use Expect for automated sessions that require a shell on a remote host (I trust that is what you mean by non-interactive). We have been using Expect on a remote Windows shell for decades. It seems a fairly common practice. Previously we used telnet, but that was no longer available in Windows 2016, so we switched to ssh (a good thing). But now behavior is different with Windows 2019. Could this have anything to do with the new ConPTY?

Could this have anything to do with the new ConPTY?

It is due to Win32-OpenSSH using the new ConPTY when it shouldn't. When ssh is wired up to expect, the correct thing for it to do is not set up a PTY, and instead act as a passthrough for a remote process's input and output streams.

@github-dub - You need to use -T (no-pty) option for automated scenarios which doesn't require the interactive ssh sessions. ssh -T user@ip.

Please try and let me know if you still have issue.

There's code in SSH that should automatically detect whether to run in -T or -t mode; those flags are only required when you want to force it one way or the other. I'm going to file a followup bug about ssh not being able to detect whether it is in interactive mode. :smile:

Thanks, to be clear, we cannot use the -T (no-pty) option because we need a remote shell. In our automated scenario Expect spawns an ssh session to obtain a remote shell to perform operations (this is an interactive session being driven by Expect). Using the same version of OpenSSH in Windows 2016, there is no issue, but with Windows 2019, we get the console spam. I demonstrated that above without using Expect. At this point, I am trying to figure out how to make the spam stop.

@github-dub -T does not turn off the remote shell, it turns off the remote expectation of interactivity that assumes that the output of the program is being wired directly up to a user's eyeballs without a program in the middle processing the data.

There's code in SSH that should automatically detect whether to run in -T or -t mode; those flags are only required when you want to force it one way or the other. I'm going to file a followup bug about ssh not being able to detect whether it is in interactive mode. 😄

I don't think we have a gap here compared to unix openssh code. If you think otherwise please feel free to create a bug with some pointers.

OK, to see if we can use it, I am trying to determine what is expected of "-T" behavior (which "turns off the remote expectation of interactivity"). When connecting to a Linux server using -T (either manually or within an Expect routine), I get a session, but no prompt (which is something that is required for use with Expect). Even if Windows 2019 allowed such a session, it would not work as it did on 2016 or Linux without "-T".

For example, an ssh session to a Linux server running OpenSSH (yields no prompt for Expect):

$ ssh -T root@ref-centos7
root@ref-centos7's password:

ls -ld
dr-xr-x---. 2 root root 268 May 28 18:02 .

exit
$

Windows 2016/2019 does not allow such a session at all:

$ ssh -T administrator@chug95
administrator@chug95's password:
shell request failed on channel 0

$ ssh -T administrator@chug09
administrator@chug09's password:
shell request failed on channel 0

Again, even if it did, it is not behavior we could use with Expect.

Hi. We have just started experiencing this issue with an "expect" based automation using renci.sshnet (via CreateShellStream). Everything works as expected on Windows 2016, but on a Windows 2019 server we get the output as per OP. We are using OpenSSH 8.6 in both cases and both appear to be the same configuration.

Was the underlying cause identified or is there a workaround?

Or can we provide further information to possibly help progress this issue.

Thank you.