Conflict between Windows 1803 OpenSSH tooling and tooling bundled with Git for Windows.

[pingzing]

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

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.17.0.windows.1
cpu: x86_64
built from commit: e7621d891d081acff6acd1f0ba6ae0adce06dd09
sizeof-long: 4

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.17134.48]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: Notepad++
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

I recently updated to the 1803 Spring Creator's update (version 10.0.17134) version of Windows, which now ships native versions of the OpenSSH tools (see OpenSSH-based client and server near the bottom).

Those automatically placed themselves in my $PATH, and I decided to start using them, instead of those bundled with Git for Windows.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

PowerShell.

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git pull

...for example, would request my ssh credentials even though the new native ssh-agent was running, and I had added my key to it.

• What did you expect to occur after running these commands?

Git for Windows would use the new, native ssh.exe on my $PATH, as well as the running ssh-agent.exe, and do things.

• What actually happened instead?

I was prompted for my key credentials.

I was able to work around this by taking advantage of the GIT_SSH environment variable, which I pointed to the new OpenSSH tooling at C:\Windows\System32\OpenSSH\ssh.exe.

I might suggest that for future releases, the installer could test for the native versions of the tools, and if those exist, not install Git for Windows versions of them.

[dscho]

I recently updated to the 1803 Spring Creator's update (version 10.0.17134) version of Windows, which now ships native versions of the OpenSSH tools (see OpenSSH-based client and server near the bottom).

Those automatically placed themselves in my $PATH, and I decided to start using them, instead of those bundled with Git for Windows.

I do have C:\Windows\System32\OpenSSH\ssh.exe but it is not in the PATH by default. Which makes me think that the best way forward would be to add an option to the installer. That option could default to true e.g. if ssh-agent.exe from that system directory exists and is running. The option should be disabled if that ssh.exe does not even exist.

Now for the fun part: this would make for an excellent first contribution! How, you ask? I am glad you asked, here is what I would suggest:

Install Git for Windows' SDK

The easiest way is to download and run the installer from https://gitforwindows.org/#download-sdk.

Alternatively, you could clone it yourself with your current Git for Windows:

git clone --depth 1 https://github.com/git-for-windows/git-sdk-64 C:\git-sdk-64
C:\git-sdk-64\git-bash.exe

Build your first installer

Just to make sure that everything works as expected, call

sdk build installer

Add the option

The options are defined in the installer/install.iss of the build-extra project. Edit it via

sdk cd build-extra
git config -e -f installer/install.iss

(this "abuses" git config to run Git's default editor).

Where?

Look for ExtraOptions, there may still be space. To test this, use a special mode of the script that normally bundles the installer, a mode designed to debug specific installer "wizard pages":

./installer/release.sh -d ExtraOptions

This looks like it runs the installer, but it really only shows one page. If you hit the Next button, it simply quits. This is great for debugging ;-)

How?

The new option could be modeled after the one enabling symbolic links: https://github.com/git-for-windows/build-extra/blob/cc9e7490b13f51a3491f6744b1c42b90b20e11f0/installer/install.iss#L1370-L1381

You probably need to use the FileExists() function with the {sys} constant (see this example how to call FileExists() in that way) to determine whether the option should be disabled.

Just like EnableSymlinksByDefault(), it could call a new function, say, UseSystemSSHByDefault() if the option is enabled, to determine whether it should be opt-in or opt-out. There are no good ways in InnoSetup's scripting language to test for a running process, but you could use the fact that we have a few MSYS2 utilities at our disposal. You could use the same trick as we do for the post-install.bat script to capture the output by redirecting to a temporary file and reading it into a string variable. The command to run would probably be {app}\usr\bin\ps.exe and it would need to be called with the argument -W to include non-MSYS2 processes.

Finally, just like with the symbolic link option, you would configure core.sshCommand (or force-unset it) depending on the user's choice.

[cleidigh]

@dscho

I came across this while attempting to work on the SSH_ASKPASS for
Visual Studio code (where I'm a collaborator)

It is related enough I thought I could also work on this as a learning process.
I successfully installed the SDK per your comments in my other post.
The installation appears to be okay but, while I followed your detailed step-by-step
instructions to the letter above, I get package manager lock errors
on a fresh install.

While also attempting to compile the openSSH package I get errors also.
These may not be related but I capture both errors in case they are.

I did search for related issues without finding anything.
Also an SO/Google search suggestion to remove the lock file
did not fix the problem.

I'm hoping to contribute on this and get my integration with VS Code
working also.

Platform is Windows 7 professional.

Installer build errors:

openSSH package errors:

Thanks in advance

[Stanzilla]

There was a recent Twitter discussion about this (https://twitter.com/nocentino/status/996895686166794240) and it seems like it should be on path by default but there are bugs preventing that for some users.

[dscho]

I get package manager lock errors on a fresh install.

[... please paste plain text as text, not as an image...]

error: could not lock database: File exists
  if you're sure a package manager is not already
  running, you can remove /var/lib/pacman/db.lck

@cleidigh that's strange.

Hmm. I also have an untracked var/lib/pacman/db.lck lying around, that's only two days old. Not sure where it came from...

Can you simply delete that file (after verifying that you have no other Git SDK Bash windows open) and re-run?

$ makepkg -s
/usr/share/makepkg/util/pkgbuild.sh: line 69: /dev/fd/62: Not a directory
[...]

OpenSSH is maintained as an MSYS2 package. These have to be built in a special Bash that you start via

c:\git-sdk-64\msys2_shell.cmd -msys

For details why this is needed, please see https://github.com/git-for-windows/git/wiki/Package-management#rebuild-packages (I know, it is hard to miss, but there are crucial differences between MSYS2 and MINGW).

@cleidigh I must ask, though, why you want to rebuild OpenSSH? Don't you rather want to work on the installer side, which is what this here ticket is all about?

Not that I think @pingzing should be proud of herself to sit by idly on the sidelines...

There was a recent Twitter discussion about this (https://twitter.com/nocentino/status/996895686166794240) and it seems like it should be on path by default but there are bugs preventing that for some users.

@Stanzilla for the record: I have a client version, and it is not installed by default. Maybe I have some company-wide settings preventing it? No idea. In any case, the reality is that we cannot rely on it to be installed by default, and that's that.

[cleidigh]

@dscho
Concerning general build issues (installer included):

After a series of install/build rounds, I think I have the main built environment working. On my main machine I'm completely running out of disk space and ended up with build errors because of not enough room. I installed on a different drive not realizing it was an HGFS partition. I have many inadvertently read on the MSYS requirement for NTFS. I believe this was the cause for some of the errors. Multiple installs perhaps caused the lock issues, that's less clear. Deleting the lock file did nothing.

A fresh install on an older system that had no git Bash or SDK installs now builds GIT and the installer.
This should give me the opportunity to work on this issue. My other issue still eludes me and I included the errors above because I thought they were related, sorry if this confused things. I can probably add a little bit of experience notes to the build instructions.

If I start the MSYS shell I still have issues building openssh. I could not get it to build as it always
complains about not finding Zlib despite it being there. I will track this in my original issue
trying to get GIT_ASKPASS to work for Visual Studio code.

Just an FYI, I have to do all computer work and programming with voice as I am disabled so my output
is on the slow side just so you know, and I will typically have some fun Dragon dictation auto corrects ;-)

[dscho]

Just an FYI, I have to do all computer work and programming with voice as I am disabled so my output
is on the slow side just so you know, and I will typically have some fun Dragon dictation auto corrects ;-)

Wow. I am impressed!

I am currently busy with day-job stuff, so I probably won't have time this week to look and see whether I can help with the other ticket. Hopefully somebody else is able to help, so that you do not have to wait for such a long time...

[cleidigh]

@dscho
I don't know about impressive, but I'm fortunate despite having ALS and a vent, I can talk which is most unusual. Continuing to work on projects like Visual Studio code and GIT keep me sane and mostly out of trouble ;-)

Hopefully I can finally get open SS each to compile, I think that's the only way to understand why
GIT_ASKPASS is not working.

[cleidigh]

@dscho
After familiarizing myself with the inno installer, I see there is already an SSH page that is presented if putty is found. I assume it makes the most sense to modify this page to be presented if either putty OR openSSH is found. Then use radio buttons to select between the three options, first being GIT SSH.

I will use your suggestion to check the processes for an agent in addition to scanning the path
when I think I've got it all posts the full logic sequence.

[dscho]

I see there is already an SSH page that is presented if putty is found. I assume it makes the most sense to modify this page to be presented if either putty OR openSSH is found. Then use radio buttons to select between the three options, first being GIT SSH.

That's a good idea!

[dscho]

BTW I was made aware that 32-bit processes (such as the InnoSetup installer) do not see any C:\WINDOWS\System32\OpenSSH\ssh.exe. They do see C:\WINDOWS\SysNative\OpenSSH\ssh.exe, though.

[dscho]

I am not sure how to progress from here. After all, there have been worrisome reports about the native OpenSSH not working as intended. Maybe we should just leave this ticket alone, or even close it, for the time being?

[dscho]

After all, there have been worrisome reports about the native OpenSSH not working as intended.

To be precise, I mean this report: PowerShell/Win32-OpenSSH#1322

[glen-84]

@dscho,

What is the best way to deal with issues like this?

1. Wait for GFW to upgrade Cygwin. OR
2. Somehow force the Windows SSH to be used ahead of the GFW SSH?
   • I'm not sure what controls the PATH order, how to change it, and whether or not that could affect Git in a negative way.

Thanks.

[dscho]

• Wait for GFW to upgrade Cygwin. OR

Git for Windows does not use Cygwin. We use MSYS2, and we build our own version of the OpenSSH package.

If you are thinking about the MSYS2 runtime, which is based on the Cygwin runtime, then I fear you'll just have to wait it out. The MSYS2 and Git for Windows projects are waiting for the v3.1.x series of the Cygwin runtime to stabilize before porting the MSYS2 runtime on top of it.

• Somehow force the Windows SSH to be used ahead of the GFW SSH?

You can easily do that.

• I'm not sure what controls the PATH order, how to change it, and whether or not that could affect Git in a negative way.

The easiest would be to avoid meddling with PATH and instead set core.sshCommand in your user-wide config.

[glen-84]

The easiest would be to avoid meddling with PATH and instead set core.sshCommand in your user-wide config.

That would only affect Git though? Using the GFW SSH binary is causing issues with tools like fzf once connected via SSH, so I think that I need to adjust the PATH to put Windows SSH first – how do I do that?

[dscho]

I have no idea what fsf is, nor do I have the bandwidth to support that tool.

[glen-84]

I have no idea what fsf is, nor do I have the bandwidth to support that tool.

I wasn't asking for support for a specific tool. Other tools are affected as well.

For now I've just added this alias to my .bashrc file:

alias ssh='winpty "C:\Windows\System32\OpenSSH\ssh.exe"'

[Okeanos]

After all, there have been worrisome reports about the native OpenSSH not working as intended.

To be precise, I mean this report: PowerShell/Win32-OpenSSH#1322

I am wondering, now that Windows ships with a newer version (OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2 as per Win32-OpenSSH#1693), whether this issue could be reexamined? Even newer 8.x versions are already being tracked in that repository as well.

Personally, I am looking at two-ish different aspects of this:

• allow (selectively) skipping parts of the bundled ssh-* executables during installation and subsequent updates; in particular the git bundled ssh-copy-id has no Windows native equivalent
• interoperability between the bundled ssh-* executables and the Windows OpenSSH (Agent) service(s), in particular Git for Windows being able to read from/write to the native ssh-agent service

My reasoning for the former is that this would prevent $PATHing issues where the ssh-* binaries are picked arbitrarily between different environments (git-bash, IDEs, other Shells, …) causing communication issues with e.g. any configured ssh-agent process. There'd simply be only a single set of these binaries available. Users would have to manually intervene if they wanted something else but it'd be their choice.

The latter should be more obvious – it should enable support for more tools to take advantage of ssh key management and allow for easier (more diverse) key management solution. For instance the KeePassXC OpenSSH implementation can already talk to the Windows agent service and be used for key management. No need to fiddle with the SSH_AUTH_SOCK or registering ssh-agent start up scripts in the .bashrc.

Does the following suggestion still apply?

I see there is already an SSH page that is presented if putty is found. I assume it makes the most sense to modify this page to be presented if either putty OR openSSH is found. Then use radio buttons to select between the three options, first being GIT SSH.

That's a good idea!

[Okeanos]

@dscho based on this issue (and my comment above) as well as #2944 I was poking around the build-extra/installer/install.issfile and checking whether I could add an option to the OpenSSH vs. Putty page that would force the installer to skip installing the binaries already supplied by Windows, i.e. everything except ssh-copy-id.

Now integrating the option on the page and maybe even detecting whether %System%\OpenSSH\ssh.exe exists (%System% apparently also links to %System32% which should cover 64Bit and 32Bit I think?) looks fairly straightforward (🤞), however, I have trouble locating at what point these Git bundled binaries are copied around, i.e. where I'd have to put a guard. Any pointers?

[dscho]

I have trouble locating at what point these Git bundled binaries are copied around, i.e. where I'd have to put a guard.

They are copied as part of the installation, via the [Files] section (which is populated by converting the output of make-file-list.sh into the file-list.iss file).

If you want to delete stuff in the ssPostInstall phase contingent on a user-specified option, just imitate what we do with Git LFS.

[dscho]

Addressed via git-for-windows/build-extra#367