git-for-windows / git

A fork of Git containing Windows-specific patches.
http://gitforwindows.org/
Other
8.28k stars 2.51k forks source link

Git GUI Password Pop-up Reappears Despite Correct Password Input. #4635

Open ShlokBharadwaj opened 11 months ago

ShlokBharadwaj commented 11 months ago

Setup

$ git --version --build-options

git version 2.41.0.windows.1
cpu: x86_64
built from commit: ff94e79c4724635915dbb3d4ba38f6bb91528260
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
$ cmd.exe /c ver

Microsoft Windows [Version 10.0.22621.2134]
# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"

$ cat /etc/install-options.txt

Editor Option: Nano
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

There is no Git GUI for Windows running in the background.

Details

Git Bash

npm install gh-pages --save-dev
npm run deploy

I expected the npm run deploy to trigger the script gh-pages -d dist from package.json and authenticate with my GitHub credentials using the password.

The Git GUI's password pop-up appears (I've been entering these commands using Git Bash until now) for entering the password. After the first attempt, it reappeared, but the same password was accepted on the second attempt. PS: The password was copied to the clipboard and was pasted both times, so definitely no wrong password.

It is not repository-specific and I've tested on multiple repositories. Still here's the link for the latest repository I've been facing the issue so far: https://github.com/ShlokBharadwaj/age-dial

dscho commented 11 months ago

Use Credential Manager: Enabled

[...]

The Git GUI's password pop-up appears [...]

These two statements are at odds with one another. Can you verify that git config --show-origin --get-all credential.helper lists credential-manager, and no empty value after that?

npm install gh-pages --save-dev
npm run deploy

While these commands probably eventually end up calling Git, this is by no means a minimal reproducer. It would require substantial setup just to get node.js let alone the gh-pages configuration.

In the absence of any more meaningful MCVE, you could try running with GCM_TRACE=1 and GIT_TRACE=1 (these can also be set to absolute paths, to avoid cluttering the console) and then studying the logs.

rimrul commented 11 months ago

Use Credential Manager: Enabled

[...]

The Git GUI's password pop-up appears [...]

These two statements are at odds with one another.

This could be git-askpass or git-gui--askpass for a remote that's accessed via SSH.

Maybe the explanation is multiple SSH keys?

ShlokBharadwaj commented 11 months ago

Use Credential Manager: Enabled [...] The Git GUI's password pop-up appears [...]

These two statements are at odds with one another.

This could be git-askpass or git-gui--askpass for a remote that's accessed via SSH.

Maybe the explanation is multiple SSH keys?

No, I checked there are no conflicts with multiple ssh keys.

ShlokBharadwaj commented 11 months ago

These two statements are at odds with one another. Can you verify that git config --show-origin --get-all credential.helper lists credential-manager, and no empty value after that?

Yes, git config --show-origin --get-all credential.helper lists

[credential]
    helper = manager

In the absence of any more meaningful MCVE, you could try running with GCM_TRACE=1 and GIT_TRACE=1 (these can also be set to absolute paths, to avoid cluttering the console) and then studying the logs.

Yes, I did try GCM_TRACE=1 and GIT_TRACE=1 while running npm run deploy and it resulted in a failure to connect to the host 0.0.0.19 on port 22, indicating that the SSH connection is encountering difficulties? Although I did use a private DNS, the logs were consistent even with no private DNS. I also checked for firewalls blocking the connection but couldn't find any and the ports were also open for SSH connections.

The error:

ssh: connect to host 0.0.0.19 port 22: Network is unreachable
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
dscho commented 11 months ago

git config --show-origin --get-all credential.helper lists

[credential]
    helper = manager

That sounds wrong. The latter is the content of a Git config file, but git config --show-origin --get-all credential.helper won't show this.

The error:

ssh: connect to host 0.0.0.19 port 22: Network is unreachable
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

That sounds like a problem in your setup where that host simply cannot be reached.

This could be git-askpass or git-gui--askpass for a remote that's accessed via SSH. Maybe the explanation is multiple SSH keys?

No, I checked there are no conflicts with multiple ssh keys.

There was no mention of conflicts. The implied suggestion was that multiple SSH keys might be available, and passwords are asked for all of them, and the different SSH keys might require different passwords.

This strikes me as the most likely explanation.

If that is the case, you will need to adapt your SSH configuration in ~/.ssh/config, most likely by editing an existing section for that Host, or if there is none, creating a new one, adding an IdentityFile directive.

If this is indeed the issue at hand, this report is not about a bug in Git for Windows, but instead it is about a problem in your setup.

ShlokBharadwaj commented 11 months ago

That sounds wrong. The latter is the content of a Git config file, but git config --show-origin --get-all credential.helper won't show this.

Yes, git config --show-origin --get-all credential.helper lists file:C:/Program Files/Git/etc/gitconfig manager and the C:/Program Files/Git/etc/gitconfig manager lists

[credential]
    helper = manager

If that is the case, you will need to adapt your SSH configuration in ~/.ssh/config, most likely by editing an existing section for that Host, or if there is none, creating a new one, adding an IdentityFile directive.

If this is indeed the issue at hand, this report is not about a bug in Git for Windows, but instead it is about a problem in your setup.

The ~/.ssh/config lists:

Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/<my_private_key>

Did the above but the issue still persisted, so I followed https://gist.github.com/alejandro-martin/aabe88cf15871121e076f66b65306610#testing-ssh-keys too and I was able to ssh into GitHub without any issue:

ssh -T git@github.com
Hi ShlokBharadwaj! You've successfully authenticated, but GitHub does not provide shell access.

Although ls in ~/.ssh lists:

config  id_ed25519  id_ed25519.pub  known_hosts  known_hosts.old

And known_hosts lists:

github.com ssh-ed25519 <key>
github.com ssh-rsa <key>
github.com ecdsa-sha2-nistp256 <key>
dscho commented 11 months ago

Okay, next guess: that innocuous npm call maybe calls Git multiple times and the separate Git invocations act independently, i.e. they do not cache SSH credentials in between.

You can verify this claim by setting GIT_TRACE=1 and then seeing what the log says when those pop-ups are shown.

ShlokBharadwaj commented 11 months ago

You can verify this claim by setting GIT_TRACE=1 and then seeing what the log says when those pop-ups are shown.

When I try to run npm run deploy with GIT_TRACE=1 I do not get the pop-ups; the command exits with an error log. The log shows that the git clone command is being traced. The issue seems to be related to the SSH connection as it tries to clone the repository, and it's unable to establish the connection due to network unreachability as I also get:

ssh: connect to host 0.0.0.23 port 22: Network is unreachable
fatal: Could not read from remote repository.

But when I try to execute the same command (npm run deploy) with unset GIT_TRACE, I do get the pop-ups.

rimrul commented 11 months ago

npm install gh-pages --save-dev

Ok, that's this gh-pages package.

It's supposed to

Publish files to a gh-pages branch on GitHub

and I don't see any config in package.json that would lead it to do something else.

ssh: connect to host 0.0.0.23 port 22: Network is unreachable

ssh: connect to host 0.0.0.19 port 22: Network is unreachable

Why is ssh trying to connect to addresses in the 0.0.0.0/8 special use address block?

ShlokBharadwaj commented 11 months ago

Why is ssh trying to connect to addresses in the 0.0.0.0/8 special use address block?

My guess is as good as yours, man! Although I did try running ssh -v git@github.com, the log does not indicate any issues with the SSH connection to GitHub.

rimrul commented 11 months ago

git remote -v only lists a single url for origin, right?

ShlokBharadwaj commented 10 months ago

git remote -v only lists a single url for origin, right?

Yes,

$ git remote -v
origin  git@github.com:ShlokBharadwaj/age-dial.git (fetch)
origin  git@github.com:ShlokBharadwaj/age-dial.git (push)
dscho commented 10 months ago

You can verify this claim by setting GIT_TRACE=1 and then seeing what the log says when those pop-ups are shown.

When I try to run npm run deploy with GIT_TRACE=1 I do not get the pop-ups; the command exits with an error log. The log shows that the git clone command is being traced. The issue seems to be related to the SSH connection as it tries to clone the repository, and it's unable to establish the connection due to network unreachability as I also get:

ssh: connect to host 0.0.0.23 port 22: Network is unreachable
fatal: Could not read from remote repository.

But when I try to execute the same command (npm run deploy) with unset GIT_TRACE, I do get the pop-ups.

Try setting GIT_TRACE to an absolute (Windows) path. It should then write a meaningful log into that file and you will at least be able to see the git command that is failing, and with a little bit of luck you can reproduce the bug without running npm at all.