ssh client on Windows7 fails "ssh_askpass: posix_spawn: No such file or directory"

[llinyu]

"OpenSSH for Windows" version
tested with versions v1.0.0.0-Beta

Client OperatingSystem
Windows 7 SP1 Professional

What is failing
On Windows 7, I can't connect to any ssh server using the ssh.exe client from this project. but putty works.
I have tried ssh.exe both in version v0.0.24.0 and v1.0.0.0-Beta without success.

I see the following:
#966

but no environment "DISPLAY" variable on my Windows 7
DISPLAY=localhost:0.0

Expected output

ssh.exe myname@192.168.10.101
myname@192.168.10.101's password:

Actual output

ssh.exe myname@192.168.10.101
key_load_public: invalid format
ssh_askpass: posix_spawn: No such file or directory
Host key verification failed.

[bagajjal]

@llinyu - Enable more debugs logs, sshd.log (with DEBUG3 enabled), ssh logs (ssh -vvv user@ip).
Please validate what's difference between putty and win32-openssh ssh.exe.

[llinyu]

I am terribly sorry. I made a mistake.
My OS has a DISPLAY environment variable I didn’t figure it out, it is the same problem as #966.

[pavelkomarov]

I don't think @llinyu made a mistake. I'm trying to get X forwarding working (long story) with the same setup described here, but it keeps failing with "ssh_askpass: posix_spawn: No such file or directory".

ssh-askpass.exe isn't a thing in your release, and it's unclear to me where ssh_askpass might live. It can be an environment variable, but why should I have to set it and what to? Clearly the code should never try to call something that doesn't exist, or it's looking for it in the wrong place. It's strange, because when my DISPLAY environment variable isn't set ssh asks for my password the normal way, and it's fine. Why shouldn't it always get my password that way? This remains a bug.

[nicksunyang]

Have you solved it?

[psz2036]

I seem to have found a workaround: create an object \dev\tty (in C:), e.g. with
mkdir \dev
echo x > \dev\tty
then Win10 ssh will prompt for password "normally".
With Xming I also seem to need "set DISPLAY=localhost:0" and to use "ssh -Y".

[cwg999]

For readability, issue was resolved from #966

Option 1:

As a workaround it seems that it is possible to create a directory C:\dev with an empty file called tty, so that the path \dev\tty can be opened.

Option 2: (Not recommended)

DISPLAY=localhost:0.0 was set. Removing/Renaming this variable resolved the issue.

[psz2036]

Sorry but unsetting DISPLAY is not a solution: you do need DISPLAY for X11 windows
(e.g. with Xming, or morr directly for the ssh options -X or -Y to make sense).

[psz2036]

(Can someone re-open this, please... or tell me how to do?)

[psz2036]

Seems that the comment of cwg999 should have been about #966 (not 996).
There (in #966) the issue is "resolved": was a bug, now corrected in sources...
so it will eventually make its way into the binary shipped with Windows10. Until
then, use the \dev\tty workaround (that is mentioned in #966, and independently
re-discovered and mentioned above).

[cwg999]

You are correct, I fixed my comment.

[idanpa]

I see the same problem with:
Windows 10 18363.535
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
After unsetting DISPLAY problem fixed, but this is not a solution for me since I would like to use X11 forwarding.