clone [windows]: Doesn't prompt to confirm unknown host keys or enter passphrase

[craigds]

Describe the bug

On the first ssh call to a new host, Kart hits this problem:

 kart clone kart@data.koordinates.com:{omitted} mydir

Cloning into '/Users/cdestigter/kart-repos/mydir/.clone'...
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
Error: Error calling git clone

Expected behaviour

The git/ssh behaviour here is to prompt for user input to authorize the new key, based on the fingerprint:

$ ssh -T kart@data.koordinates.com
The authenticity of host 'data.koordinates.com (54.66.53.126)' can't be established.
ED25519 key fingerprint is SHA256:ZzjcJMbJqqnIvugXsT2dKQUtKnPfUmUKEdKwuhLp+Cw.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'data.koordinates.com' (ED25519) to the list of known hosts.
Hi! You've successfully authenticated, but Koordinates does not provide shell access.

HELPER MODE

• On MacOS this seems to be caused by helper mode - setting KART_USE_HELPER=0 fixes it.
• On Windows it must be caused by something else - Kart's Windows build doesn't have helper mode.

Output
Add the output you're seeing to help explain your problem.

**Version Info **

• Kart v0.12.3 on Windows 10
• reproduced by me on Kart v0.13.0rc1, MacOS 13.3.1 on M1 but ONLY with helper mode enabled (so slightly different cause)

[craigds]

Similarly if the user's SSH key has a passphrase, kart isn't prompting for it and the auth is simply failing.

GIT_SSH_COMMAND="ssh -v" yields this:

debug1: read_passphrase: can't open /dev/tty: No such device or address

Reported on windows, so isn't solely a helper-mode thing as helper-mode isn't active on Windows.

[craigds]

Tested working on MacOS now (Kart 0.14rc2) due to the fixes in #856 👍

Most likely still fails on Windows.

[olsen232]

Git / ssh on windows still can't prompt the user for extra input. This is because we run git with stdout connected to a pipe, and git detects this and won't prompt the user. (For whatever reason, this doesn't happen on macos / linux - the logic must be slightly different on the different platforms, or, they use different mechanisms to prompt the user...).
We need git to be connected to a pipe if we want to be able to listen to its output and detect why it failed. We do immediately echo its output to the user anyway - for progress reporting reasons - so if we could just convince git that it has a tty, then it would work as-is.

Possible fix - set up a pseudo-tty and run git connected to that, and somehow echo whatever is output to the pseudo-tty to stdout.

[rcoup]

Think we could file a question/issue with Git For Windows and see if they have a known solution? It's basically developed by MS so if anyone will know, they will.

[olsen232]

git-for-windows/git#1613 is relevant

[olsen232]

Spent a while today modifying the code to capture any of stdout and/or stderr, instead of always capturing both. But it was to no avail when I realised that stderr is the one we want to capture, and, stderr is the one that git or the ssh-thingy checks for isatty() before using it to prompt the user. If these were on different fds, we could capture one, the other one would prompt, everything would work fine