ssh client on Windows7 fails with: ssh_askpass: fork: No such file or directory

[christian-korneck]

Please answer the following

"OpenSSH for Windows" version
((Get-Item (Get-Command sshd).Source).VersionInfo.FileVersion)
tested with versions 0.0.23.0 and 0.0.18.0

Server OperatingSystem
((Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows nt\CurrentVersion\" -Name ProductName).ProductName)
any server on any OS - it's a client issue (tested against various servers, both Linux and sshd on localhost running on Win7 SP1 Ultimate)

Client OperatingSystem
Windows 7 SP1 Ultimate

What is failing
On Windows 7, I can't connect to any ssh server using the ssh.exe client from this project. The servers that I've tested all have password auth. The key error message is: ssh_askpass: fork: No such file or directory.

On Windows 10 (tested with Win10-1709) and on Windows 8.1, the same ssh.exe binary works as expected (connections against the same servers).
On the Windows 7 host, the same connections work using a different ssh client (i.e. putty).
Same effect both with the 32bit and 64 bit ssh.exe.

I have tried ssh.exe both in version 0.0.23.0 and 0.0.18.0 (the version that ships as capability/optional feature in Win10-1709) without success.

Expected output

> ssh.exe myusername@tty.sdf.org
myusername@tty.sdf.org's password:
NetBSD 7.1 (GENERIC.201703111743Z)

     *    . @%@%@%@%@%@%@ (    )
     (      {   happy   }  \  (   *
      ) *   { birthday! }   )    (
     (    @%@%@%@%@%@%@%@%@       ) '
   +      {    SDF 30!    }  *   (
          {  1987 - 2017  }    .    )
    jgs   {    June 16    }        (
  *      @%@%@%@%@%@%@%@%@%@    +

Actual output

> ssh.exe myusername@tty.sdf.org
key_load_public: invalid format
ssh_askpass: fork: No such file or directory
Host key verification failed.
PS C:\Windows\System32\WindowsPowerShell\v1.0>

[christian-korneck]

ok, I think I figured it out. On my Windows 7 machine the environment variable DISPLAY=localhost:0.0 was set. Removing/Renaming this variable resolved the issue.

While it was set, my c:\Program Files\OpenSSH\ssh.exe was trying to execute c:\Program Files\OpenSSH\usr\X11R6\bin\ssh-askpass.exe, which doesn't exist (seen with a procmon trace).

[manojampalam]

Thanks for following up.

[pavelkomarov]

Why does it matter that the DISPLAY environment variable is set? That shouldn't lead to something asking for a password any differently than it would otherwise!

I am experiencing the same trouble with X11 forwarding described here, but I can't leverage their solution of setting the DISPLAY on the client side, because OpenSSH then throws these complaints about permissions being strangely denied.

[christian-korneck]

I agree with @pavelkomarov . It looks like a bug to me. Any chance that this issue could get re-opened?

[Error-101]

I agree with @pavelkomarov as well. Why should the display variable matter?

[duhd1993]

Why does it matter that the DISPLAY environment variable is set? That shouldn't lead to something asking for a password any differently than it would otherwise!

I am experiencing the same trouble with X11 forwarding described here, but I can't leverage their solution of setting the DISPLAY on the client side, because OpenSSH then throws these complaints about permissions being strangely denied.

Wish you found a solution.
The posix_spawn related error seems related to cmd, when I use powershell, the error is gone. but x forwarding still doesn't work.

[forester-guo-gmail-com]

@christian-korneck 's solution worked.
In my Windows 10 cmd terminal, DISPLAY=:0.0, scp failed with: "
CreateProcessW failed error:2
ssh_askpass: posix_spawn: No such file or directory
Host key verification failed.
lost connection"
I removed the env variable by "set DISPLAY=". Then scp copied files successfully.

[pavelkomarov]

Yeah, but it's a work-around. The bug remains.

[Olof-Lagerkvist]

This is an interesting bug. It happens because when DISPLAY is defined and there is no accessible tty (console, terminal, etc), it wants to fallback to requesting password by some external application call. Now, the problem is that the check for an available console is done by opening /dev/tty. This works perfectly well on *nix platforms, but on Windows the corresponding thing should really be to open CON or CONIN$ instead.

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. Just tested that and it seems to work.

I'll try to build a version with CON instead of /dev/tty for Windows builds and see what happens.

[Olof-Lagerkvist]

Yes. At line 457 in define.h, changed:

#ifndef _PATH_TTY
# define _PATH_TTY "/dev/tty"
#endif

to

#ifndef _PATH_TTY
# ifdef _WIN32
# define _PATH_TTY "conin$"
# else
# define _PATH_TTY "/dev/tty"
# endif
#endif

And everything seems to work correctly even with DISPLAY variable set now. It even sets up X11 forwarding correctly as far as I can see (provided XauthLocation is set to a working xauth setup in ssh_config).

[filips123]

@LTRData So this is now fixed? When it will be available in Windows?