Unable to store SSH host key in cache using Plink

[bviktor]

• 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? 32-bit or 64-bit? Include the
  output of git version as well.

Git portable 2.9.2 64 bit.

$ git --version
git version 2.9.2.windows.1

• Which version of Windows are you running? 32-bit or 64-bit?

Windows 10 64-bit 10586.494

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

Portable install thus defaults.

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

Using Pageant and Plink from c:\tools\putty, git is located at c:\tools\git2. Private key loaded into Pageant, public key added to Gerrit server. Trying to clone repos from Gerrit via SSH.

Details

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

Bash.

• 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 clone ssh://viktorb@gerrit.fooworks.com:29418/admin2.git

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

To successfully clone the repo.

Cloning into 'admin2'...
remote: Counting objects: 2, done
remote: Finding sources: 100% (2/2)
remote: Total 2 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (2/2), 209 bytes | 0 bytes/s, done.
Checking connectivity... done.

• What actually happened instead?

Git is asking me to verify the host key fingerprint but I'm unable to do so, it becomes unresponsive. Eventually I press Ctrl+C.

Cloning into 'admin2'...
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 1024 <fingerprint>
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n) y



viktorb@foo013 MINGW64 ~/Documents/git
$ y
bash: y: command not found

viktorb@foo013 MINGW64 ~/Documents/git
$

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

This is an internal Gerrit server, though I don't think it is limited to this instance, it most likely occurs on every SSH clone where the host key isn't cached.

Workaround: attempt a connection with PuTTY to gerrit.fooworks.com on port 29418 which asks me to accept and cache the host key. After that, I can clone using git as well.

It's most likely just an interface bug where Git doesn't receive user input at the prompt and thus keeps waiting forever.

[dscho]

This is a known issue and one of the reasons we discourage using plink with Git.

[bviktor]

So if it's known it doesn't need to be fixed? Or is it an issue in Plink instead?

[PhilipOakley]

----- Original Message -----

So if it's known it doesn't need to be fixed? I'm not following you :)

What is known is that there is an incompatibility between the default G4W method, and the plink way of working.

The link to the know issues gives:

"If configured to use Plink, you will have to connect with putty first and accept the host key.".

So the fix (for users with plink) is for those users to connect first as described...

So in one sense it's fixed....

Philip

[bviktor]

Well, there's a difference between "workaround" and "fix" so I'm not sure why such an issue is closed instantly, but oh well.

[fourpastmidnight]

You might want to check out a project called ssh-pageant and see if that helps you to "integrate" PuTTY with Git for Windows. I don't recall if it's a part of the current Git for Windows distribution--but if not, I believe the project is located here on GitHub. You can also search the Git for Windows issue list for it, because the developer of it was working on getting it part of Git for Windows at one point. Barring that, as @dscho said, it's a known issue--not a bug--and it's not something Git for Windows can fix.

[dscho]

@bviktor you seem to assume that we did not spend hundreds of hours to resolve the precise issue you reported. This is not so. And even if it were, I strongly suggest a change of tone, especially since this is repetitive behavior. You have been treated respectfully, been provided with helpful advice. I expect you to return the favor.

[bviktor]

@dscho again, I'm not sure what our attitude has anything to do with the fact that the issue exists :)

Anyway, if it's not a Git bug (as I was told here) then fine, the issue being closed is appropriate. If you told me the reason why you closed it (instead of saying "I know about this issue so I close it", which makes no sense to me), I wouldn't have asked in the first place.

[fourpastmidnight]

@bviktor I'm glad you found some information given here useful. However, @dscho is right. You indicated in this issue that you searched the issues list and was unable to find an open or closed issue to help you resolve your issue. I know for a fact that there are at least two issues that would have helped you--because that's where I got the information from which I shared with you, not to mention that @dscho linked to one directly.

The fact is, people have spent hours helping you answer a question which has already been answered many times over, and there are plenty of actual issues that the limited resources of this project are trying to resolve. Please, next time, make an effort to actually search the issues list before opening an issue to avoid situations like this. You might also want to try a simple internet search where this particular issue has also been discussed at length in various forums and blog posts. You'll find that a little bit of effort on your part will go a long way in helping us more effectively provide guidance to you when you experience an actual issue with Git for Windows itself.

[PhilipOakley]

Hi All,

I'd just like to remind us all, that email / text messaging can be a rather poor communication method when it comes to ensuring we all understand the issues from all sides, and have fully covered all the points effectively. I too fail often. Often our responses 'tantilise without telling', [as a no-excuse, it's very common in almost all forms of technical discussions]
@bviktor I'm glad you found some information given here useful. However, @dscho is right. You indicated in this issue that you searched the issues list and was unable to find an open or closed issue to help you resolve your issue. I know for a fact that there are at least two issues that would have helped you--because that's where I got the information from which I shared with you, not to mention that @dscho linked to one directly.

The fact is, people have spent hours helping you answer a question which has already been answered many times over, and there are plenty of actual issues that the limited resources of this project are trying to resolve. Please, next time, make an effort to actually search the issues list before opening an issue to avoid situations like this. You might also want to try a simple internet search where this particular issue has also been discussed at length in various forums and blog posts. You'll find that a little bit of effort on your part will go a long way in helping us more effectively provide guidance to you when you experience an actual issue with Git for Windows itself.

One issue I do find, in general, is that the searching of the Github interface isn't as 'obvious' to all as it could be, the github help isn't as findable as it should be and it appears that most users don't find any prior issues even when they try and look. We can then make it worse by not expressly giving the relevant links when we look ourselves, though typically we have prior knowledge they are there, but don't look ourselves to check that (the user's) search terms would find them.

https://github.com/git-for-windows/git/issues?utf8=%E2%9C%93&q=plink%20ssh%20keys gives 6 (closed) issues headings, while
https://github.com/git-for-windows/git/issues?utf8=%E2%9C%93&q=plink gives 1 open and 12 closed.

As you @bviktor can see the issue does have some history.

I notice that on the FAQs page (https://github.com/git-for-windows/git/wiki/FAQ) there is no 'in text' mention of "Issues", (there are 4 others that feel to be 'outside of the wiki' or not directly relevant). It's most unfortunate that the "Issue reporting guidelines" page have just dropped of the righthand menu list!

Meanwhile, in soft grey(*), there is an issues 'title' between the code and pull request, but the eye is drawn rightward to the Wiki title with it's red overbar. If we do spot, and follow, that (the 'issue') link, we are dropped onto a page listing the open issues for the user to scroll down and see if any title catches their eye.

I certainly didn't find the github search box that appealling as it invites the additions of text at the end, rather than the deletion of qualifiers (which nervous users are probably loathe to do) before entering their search word (thus only open issues are found).

If we want users to search the issues history, we'll need to 'help' them do it right/ do it better.

Philip

(*) don't get me started on soft grey fonts. They are the scourge of modern web design and greatly reduce readability (check out an eye chart near you ;-)...

[landstander668]

You might want to check out a project called ssh-pageant and see if that helps you to "integrate" PuTTY with Git for Windows. I don't recall if it's a part of the current Git for Windows distribution--but if not, I believe the project is located here on GitHub.

ssh-pageant is indeed included in Git for Windows, starting with the 2.8.2 release, but needs to be explicitly configured. Instructions for doing so can be found in the Wiki here.

[julianmontague]

For anyone else trying to reckon with this issue, I have done some research for any future souls who wish to attempt to fix this.

Here is the first GitHub issue I could find that mentions this problem: #482. I do not have an exhaustive listing because, as PhilipOakley mentioned, GitHub search is difficult to use (on top of the fact that plink is mentioned in many issues unrelated to this one, so I'm not sure how much blame the search system can take). However, here is another issue related to this problem: #713.

And, now, what I believe to be the very first issue mentioning this problem: Issue 96 on Google Code.

I found it by following a link to the mailing list mentioned in this comment in issue 462, which was in turn linked to in #482.

Issue 96 was referenced in this message in that thread:

The "acceptance of new host keys" issue (see #96) is not random but a known Plink issue.

All it took after that was spelunking through the Wayback Machine in order to get around the redirect that remains in the Google Code Archive, making it impossible to view any issues from the project on the live archive site.

If I for some reason become motivated, I would like to add a link to one of these issues in the known-issues list such that people can see that this has been reported before. But given that it hasn't been mentioned in a few years, perhaps it's not worth the effort.

So, TL;DR, weary traveler: this issue has existed since 2008 and all signs point to it being a problem with Plink. If my memory serves me correctly, the PuTTY project does not accept patches but if you are at all interested I suggest you check out their homepage.

As for myself, I'm switching to Linux soon so I will be leaving PuTTY behind.