"external OpenSSH" configuration causes "Pseudo-terminal will not be allocated because stdin is not a terminal" in Git Bash

[richardebeling]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

I installed Git-2.43.0-64-bit.exe on Windows 10 Pro (64-bit) and selected "Use external OpenSSH" when prompted.

The "external OpenSSH" installation is the one provided by windows by default:

$ which ssh
/c/Windows/System32/OpenSSH/ssh

$ ssh -V
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2)

$ git --version --build-options
git version 2.43.0.windows.1
cpu: x86_64
built from commit: 4b968f3ea3b32a7bc50846bab49f3f381841d297
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

$ cmd.exe /c ver
Microsoft Windows [Version 10.0.19045.3693]

$ type "C:\Program Files\Git\etc\install-options.txt"
Editor Option: VIM
Custom Editor Path:
Default Branch Option: main
Path Option: Cmd
SSH Option: ExternalOpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Disabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Enabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

Details

Inside Git Bash, when I try to connect to some SSH server, the SSH client prints:

Pseudo-terminal will not be allocated because stdin is not a terminal.

As a MCVE, you can try to connect to github.com:

$ ssh git@github.com
Pseudo-terminal will not be allocated because stdin is not a terminal.
[...]

I'm running an interactive shell session in Git Bash, and so I'd expect SSH to correctly determine this and allocate a pseudo-terminal.

For any SSH server that actually allows an interactive shell session (github.com does not allow this), you will be greeted by the message of the day, but the shell running will not be started in interactive mode. As a consequence, it will seem like the connection hangs, as no prompt will be printed. Ctrl+C will terminate the connection.

As a workaround, you can pass -tt to ssh to force tty allocation. This will get you a prompt. However, the SSH session still behaves weirdly, e.g.

• Ctrl+C still terminates the connection
• Tab will not autocomplete, but send a literal tab

This may be a different bug though.

In Windows PowerShell and the Windows Command Prompt, the ssh client behaves as expected.

An example of a "broken" shell session:

$ ssh vagrant@127.0.0.1 -p 2222 -i .vagrant/machines/default/virtualbox/private_key
Pseudo-terminal will not be allocated because stdin is not a terminal.
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-87-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Thu Nov 23 22:38:48 UTC 2023

  System load:  0.0               Processes:               101
  Usage of /:   3.6% of 38.70GB   Users logged in:         0
  Memory usage: 20%               IPv4 address for enp0s3: 10.0.2.15
  Swap usage:   0%


Expanded Security Maintenance for Applications is not enabled.

0 updates can be applied immediately.

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status


The list of available updates is more than a week old.
To check for new updates run: sudo apt update

whoami  # bash is running non-interactively, so the prompt is missing, and .bashrc wasn't executed
vagrant
last
vagrant  pts/0        10.0.2.2         Thu Nov 23 22:21 - 22:21  (00:00)
reboot   system boot  5.15.0-87-generi Thu Nov 23 22:21   still running

wtmp begins Thu Nov 23 22:21:24 2023

[dscho]

Inside Git Bash, when I try to connect to some SSH server, the SSH client prints:

Pseudo-terminal will not be allocated because stdin is not a terminal.

As a MCVE, you can try to connect to github.com:

$ ssh git@github.com
Pseudo-terminal will not be allocated because stdin is not a terminal.
[...]

This is mentioned in the Known Issues in our Release Notes:

• Some console programs, most notably non-MSYS2 Python, PHP, Node and OpenSSL, interact correctly with MinTTY only when called through winpty (e.g. the Python console needs to be started as winpty python instead of just python).

And indeed it works with winpty:

$ winpty /c/Windows/system32/OpenSSH/ssh git@github.com
git@github.com: Permission denied (publickey).

Another approach has to do with this:

$ type "C:\Program Files\Git\etc\install-options.txt"
[...]
Enable Pseudo Console Support: Disabled
[...]

You could turn on support for Pseudo Terminals:

$ MSYS=disable_pcon /c/Windows/system32/OpenSSH/ssh git@github.com
Pseudo-terminal will not be allocated because stdin is not a terminal.
git@github.com: Permission denied (publickey).

$ MSYS=enable_pcon /c/Windows/system32/OpenSSH/ssh git@github.com
git@github.com: Permission denied (publickey).

The installer even suggests (on the page titled "Configuring the terminal emulator to use with Git Bash") to

Use Windows' default console window
[...] which works well with Win32 console programs such as interactive Python or node.js [...]

[richardebeling]

I'd argue that the average user doesn't read all the descriptions in the installer, and maybe doesn't even have the background knowledge to understand them. If there's a default value and I don't see any immediate reason to change it, I'll just accept it. Just from the "Pseudo-terminal will not [...]" message, I wasn't able to find any of the documentation/hints/workarounds you linked.

In any case, I think it would be desirable that the default installation works nicely, even if I choose to use Windows' SSH client. Is there a change we could enable pseudo console support by default? MSYS2 has ConPTY support enabled by default since 2022-09, this seems to be what setting MSYS=enable_pcon does. The installer says "but unfortunately, this is not quite stable yet" -- is there a list of things that break with this setting somewhere?

Alternatively, I think it is by now feasible to default to Windows' console window instead of MinTTY. This is related to #3689. Here, backwards compatibility with Windows Vista was given as a reason not to do this. However, all Windows versions <= 8.1 are at their end of life and don't get security updates anymore, so I think it's fair to update defaults for easier usability for modern systems. (Edit: Note: MSYS2 dropped support for Windows <=8.0 in 2023-01)

[rimrul]

I'd argue that the average user doesn't read all the descriptions in the installer, and maybe doesn't even have the background knowledge to understand them.

We can only show them the information, but we can't force them to understand it.

In any case, I think it would be desirable that the default installation works nicely, even if I choose to use Windows' SSH client.

It's not default then anymore, is it? But I guess it would make sense to add some hints like "You've enabled Feature X, it is recommended to also enable Feature Y".

Alternatively, I think it is by now feasible to default to Windows' console window instead of MinTTY. This is related to #3689. Here, backwards compatibility with Windows Vista was given as a reason not to do this.

Old builds of Windows 10 and Windows Versions going back to Windows Vista to be precise. And all of them except Vista are still supported. We're currently still supporting Windows 7 and 8.0 until we switch to a Cygwin 3.5.x based msys2-runtime and even then we have no current plans to discontinue Windows 8.1 support.

I still stand by what I wrote back then:

our support for new Conhost features like ConPTY is still experimental. Once that becomes stable we might consider flipping the default to Conhost on fresh installs on new Builds of Windows 10.

We could default to conhost and conpty on Windows 10, version 1809 and newer, if we deem it stable enough. I'm not the right person to judge if it is stable enough though.

easier usability for modern systems.

[citation needed]

Our bundled OpenSSH is usually more modern than system OpenSSH and usability with that is pretty good, even without ConPTY.

[dscho]

our support for new Conhost features like ConPTY is still experimental. Once that becomes stable we might consider flipping the default to Conhost on fresh installs on new Builds of Windows 10.

We could default to conhost and conpty on Windows 10, version 1809 and newer, if we deem it stable enough. I'm not the right person to judge if it is stable enough though.

Judging from my experience, ConPTY support has become slightly more robust, and since it was done (unfortunately) in a way that made the disable_pcon mode substantially worse, we probably need to make the switch, too, following MSYS2's decision.